Method and apparatus for dynamic aircraft trajectory management

ABSTRACT

Disclosed are algorithms and agent-based structures for a system and technique for analyzing and managing the airspace. The technique includes managing bulk properties of large numbers of heterogeneous multidimensional aircraft trajectories in an airspace, for the purpose of maintaining or increasing system safety, and to identify possible phase transition structures to predict when an airspace will approach the limits of its capacity. The paths of the multidimensional aircraft trajectories are continuously recalculated in the presence of changing conditions (traffic, exclusionary airspace, weather, for example) while optimizing performance measures and performing trajectory conflict detection and resolution. Such trajectories are represented as extended objects endowed with pseudo-potential, maintaining objectives for time, acceleration limits, and fuel-efficient paths by bending just enough to accommodate separation.

RELATED APPLICATIONS

This application claims priority to the following U.S. patentapplications, the subject matters of which are incorporated herein bythis reference for all purposes, including the following:

U.S. Provisional Patent Application Ser. No. 61/435,999, filed on Jan.25, 2011, entitled Airspace Phase Transitions And The Traffic Physics OfInteracting 4DTrajectories; and

U.S. Provisional Patent Application Ser. No. 61/450,453, filed on Mar.18, 2011, entitled Airspace Phase Transitions And The Traffic Physics OfInteracting 4DTrajectories.

In addition, the subject matter of the following commonly owned U.S.patent applications, filed on even date herewith, is incorporated hereinby this reference for all purposes:

U.S. patent application Ser. No. 13/358,310, now U.S. Pat. No.8,554,458, entitled System and Method for Planning, DisruptionManagement, and Optimization of Networked, Scheduled or On-Demand AirTransport Fleet Trajectory Operations.

FIELD OF THE DISCLOSURE

The disclosure relates traffic control and monitoring, and, morespecifically, to systems and techniques for control and monitoring airtraffic within an airspace.

BACKGROUND OF THE DISCLOSURE

The science of traffic physics is a new field emerging at the boundaryof agent-based modeling and statistical physics. It addresses thestatistical properties of large numbers of self-propelled objects actingon their own behalf. To date, the science has largely been applied toroadway vehicle dynamics because of the significant societal andfinancial import and because the problem is simplified by geometricalconstraints. In addition, road traffic systems offer ready access tolarge amounts of data. This research has applicability to othermany-agent systems in addition to roadways. The utility of the scienceis the ability to define systemic measures that are independent of theparticular behaviors of each agent in a traffic system and independentof details of the system itself (such as geometric characteristics),much as the pressure exerted by a gas on its container is independent ofthe details of motion of each individual molecule in the gas andindependent of the shape of the container.

Physical systems consisting of many particles are often characterized interms of phase, such as liquid, solid, or gaseous. The phase is aproperty of an entire system, rather than of any of its particularcomponents. Systems of interacting agents in freeway traffic have beenshown both theoretically and empirically to exhibit phases thatcorrespond to free-flowing (“liquid”) or jammed (“solid”) traffic.Traffic also has phases that do not have analogues in common physicalsystems, such as backwards-flowing waves of stalled traffic mixed withmoving traffic.

If a system has more than one phase, it will have boundaries betweenphases. Varying a control parameter (such as temperature moving waterfrom ice to liquid) can generate a phase transition. In purely physicalsystems, control parameters are usually external, though in engineeredor biological systems they can be internal and adaptive. The set ofphenomena around phase transitions are called critical phenomena, andinclude the divergence of the correlation length, ergodicity breaking(not all possible states of the system reachable from a givenconfiguration), and other phenomena. The divergence of the correlationlength is of particular interest in traffic systems because it meansthat a perturbation in one part of a system can affect another part at alarge distance, with implications for controlling methodologies.

Just as molecules obey certain laws (conservation of energy and momentumand the equipartition of energy), the traffic “molecules” (agentsrepresenting vehicles with drivers) obey simple laws implemented in afully distributed fashion—attempting to get where they are going asquickly as possible (with an upper limit) and interacting with othervehicles, such as avoiding collisions and following at a safe distance.Even though systems of self-propelled entities do not obey the sameconservation laws as traditional equilibrium statistical systems do,many of the traffic physics systems that have been recently proposedhave mappings onto well-studied equilibrium systems.

An example of this is the highly simplified collective motion model ofVicsek et. al., (T. Vicsek, A. Czirok, E. Ben Jacob, I. Cohen, and O.Schochet, “Novel type of phase transitions in a system of self-drivenparticles”, Physical Review Letters, Vol. 75 (1995), pp. 1226-1229)inspired by the computer graphics work of Reynolds (C. Reynolds,“Flocks, birds, and schools: a distributed behavioral model”, ComputerGraphics, Vol. 21 (1987), pp. 25-34). Their model consists of acollection of entities all traveling at the same invariant speed in twodimensions but whose headings are allowed to vary. At each update cycleof the model, the directions of the particles are updated by thefollowing rule: The direction is updated by taking the average of thedirections of the neighboring particles in a radius r and adding a noiseterm. v_(i)(t+1)=(v(t))_(r)+θ_(i). The end result is a textbook phasetransition as depicted in FIG. 1 which illustrates the relationshipbetween Phase Transitions and Noise, where the y-axis denotes averagealignment of particles, the x-axis denotes noise.

At low noise values (η), the entire system tends to align. As noiseincreases, uncorrelated motion results. As the system size becomeslarger (the multiple curves shown) the curves asymptote to a singlecurve, another classic indicator of phase transition behavior. If oneapproaches the phase boundary from the high-noise side (large values ofη) then there is a sudden emergence of preferred direction in the model;this is the phase transition boundary. As the system size approachesinfinity, the onset of preferred direction becomes infinitely sharp.

A somewhat more realistic model than the previous one has been developedby Helbing (D. Helbing, “Traffic and related self-driven many-particlesystems”, Reviews of Modern Physics, Vol. 73, 2001, pp. 1067-1141; D.Helbing, et al., “Micro- and macro-simulation of freeway traffic”,Mathematical and Computer Modeling, Vol 35, 2002, pp. 517-47) and othersand corroborated with simulation and empirical data. In vehicle traffic,throughput (or capacity) of a roadway increases with density to acertain point after which a marked decrease is observed; hence, theemergence of a traffic jam. In this model the driving parameter isvehicle density per length of roadway, not noise. The two models andtheir effects are related: The higher the density the greater thefrequency of correcting behavior (speeding up, slowing down). Eachincidence of correcting behavior is associated with uncertainty (noise).Instead of the noise being applied externally, it is endogenouslygenerated by adaptive agent behavior. When density is low, overshootsand undershoots do not propagate very far because of the “slack” in thesystem.

At a certain critical point, these perturbations ricochet throughout thesystem, generating a cascade of corrections and pushing the system intoa radically different configuration (the “traffic jam” phase). The noisegenerated with each speed correction creates an equal or greater numberof other speed corrections and the system cannot stably return to theinitial configuration. This generates a phase transition. FIG. 2illustrates a plot of a freeway traffic phase diagram in which thedotted line represents theoretical prediction for pure truck traffic,the solid line represents pure automobile traffic, and the black crossesindicate simulation results for mixed traffic, and the grey boxesindicate actual freeway measurements.

In prior art, systems and methods for separating aircraft has beenlimited to the use of radar, radio, conflict-probe and other software,and air traffic controller instructions to aircraft. The limitation ofthe past method is that it does not allow for management of trajectoriesbased on the probabilities of future conditions in the airspace.Extending the traffic physics paradigm to the airspace problem requiressome modifications and extensions to the current models in theliterature. For the most part, aircraft have intent, and this factorneeds to be reflected in any realistic model of the airspace. TheHelbing model discussed above effectively incorporates intent, as theparticles are constrained to move in one dimension, with intent to reachanother location. The Vicsek model, though it has similarities to flightmodels, does not incorporate intent because there is no preferreddirection of motion. Due to iterated directional corrections and theinfluence of noise, the initial direction of a particle may change by alarge amount over time, and there is no notion of the initial (or any apriori) direction being “preferred” or “optimal”, though the modelspontaneously generates preferred direction under the right parametersettings.

Accordingly, a need exists for an air traffic control system andtechnique that incorporates intent in a natural and computationallyefficient way.

A further need exists for a system and technique to predict phasebehaviors in an airspace.

Another need exists for the ability to develop a traffic physics/phasetransition description and algorithmic measures to predict when anairspace will approach the limits of its capacity.

Still a further need exists for a system and technique to control anairspace phase state through management of bulk properties of manytrajectories simultaneously.

Yet another need exists for the ability to identify effective approachesfor separation assurance for aircraft trajectories (as contrasted withseparation for aircraft only) in an airspace.

A still further need exists for algorithms, agent-based structures andmethods for analyzing and managing the complexity of airspace states,while maintaining or increasing safety, involving large numbers ofheterogeneous aircraft trajectories.

Additionally, a need exists for continuous replanning of flight paths soas to continually adjust all future flight paths to take into accountcurrent and forecast externalities as knowledge of these forecastsbecome available.

Finally, the need exists for this continuous replanning to beaccomplished at computing speeds many times faster than real time, so asto complete the replanning in sufficient time to implement air trafficcontrol adjustments in advance of the predicted unwanted phasebehaviors.

SUMMARY OF THE INVENTION

The system and technique disclosed herein utilize fully dynamicalaircraft trajectories, and managing of the airspace in terms of its bulkproperties. In the system and techniques disclosed herein, entireregions of airspace are characterized as solvable (or not)—within thelimits of available computational resources—while accounting for thephysical constraints of aircraft using the airspace, as well asshort-lived constraints such as weather and airport closures. System andtechnique disclosed herein utilizes many “agents” representing aircrafttrajectories that optimize their individual fitness functions inparallel. In addition, trajectory replanning comprises part of thedynamic trajectory management process. In this system and technique, thecontinual replanning of trajectories incorporates objective functionsfor the separation and maneuvering of the aircraft, the Air NavigationService Provider (ANSP) business case considerations, as well as apseudo-potential “charged string” concept for trajectory separationcoupled with trajectory elasticity, together provide for the optimalmanagement of airspace. The algorithms support monitoring of thecollective dynamics of large numbers of heterogeneous aircraft(thousands to tens of thousands) in a national airspace undergoingcontinuous multidimensional and multi-objective trajectory replanning inthe presence of obstructions and uncertainty, while optimizingperformance measures and the conflicting trajectories.

Disclosed herein is a system and technique for utilizing a DynamicalPath (DP) as a way to accurately represent dynamical trajectoriescomputationally. Such a system may be implemented with a DesktopAirspace software platform in which simulation of entire real andimagined airspaces enables research, planning, etc. With computationalmodeling, highly scalable, high performance simulations may be createdwith scales to 10000s of trajectories, so an entire airspace can bemodeled computationally. The system is designed to be fast, so themodels can run substantially faster than real time. With a computationalmodel, trajectories are modeled like wiggling strands of spaghettistaying away from each other and from storms. Following are briefdescriptions of the basic elements of the disclosed trajectorymanagement model.

Central to the focus of the computational modeling of trajectories isthe concept of is continuously replanning the trajectories in the faceof disruption. Dynamical Paths live in the context of many other DPs,also continuously replanning their trajectories. The disclosed systemenables managing of a suite of trajectories to operate safely andefficaciously. Such approach not only applies to computation modelingand simulations but may be extended to and applied to actual flight inthe airspace.

In systems with many elements, disruptions are endemic; hence,continuous replanning is required. Such approach is a departure from the“static” mind-set, which attempts to plan once and for all, seekingaccurate trajectory predictions far into the future. Such a legacystatic paradigm encounters and deals with disruption episodically, butnot systematically. In contrast, the dynamical paradigm disclosed hereinassumes continuous disruption, dealing with disruption systematicallyand continuously. Even the best plan is only best in the context ofother plans—hence, what is “best” can change dynamically and such changecan ripple through the system, forcing others to re-plan as well.

Computationally, Continuous Replanning has a time granularity of DeltaT. The Delta T value is set according to the agility required to reactin a timely way to disruptions. The Delta T is mediated by availablecomputational resources, communications latencies, and other factorsaffecting the lead times required to take management actions toimplement flight path changes derived from the system and technique. TheDelta T need not be a constant over time—replanning time frequency maychange. However, our algorithms prefer that replanning be synchronousacross all Dynamical Paths.

A Dynamical Path is made up of continually changing Paths via theContinuous Replanning process. In the contemplated computational model,a Path lives in four dimensions (x, y, z+time space)—similar in this wayto a “string” in String Theory in physics. Time on a Path is unrelatedto the “actual” simulated Present Time (see below) of the aircraft. Bydefinition, the points in the actual past on a Path are the same as thepoints actually flown. The points in the actual future of the aircraftare open to be planned per system/aircraft objectives.

Path Node or Node is a 4D “string” object made up of Path Nodes in 4Dgeometric space. A Path Node has 7 scalar values: x, y, z location; x,y, z velocities; and time. The Path Nodes are ordered in time—the timesin the Path Nodes of a Path ascend monotonically. A set of Path Nodesuniquely defines a Path (one of many Paths which make up a single DP).Path Nodes are used as Control Points (CP) for changing or modifyingPaths. Changing the values of a single Path Node effectively changes thePath. Hence, Path Nodes function as Control Points for altering a Path.Paths are made up of Path Nodes and the interpolated points between PathNodes. Interpolated points between Path Nodes are computed using cubicsplines. Hence Paths are continuous mathematical functions, as are thevelocities. Accelerations are not necessarily continuous using thisapproach. However, Path Nodes are carefully chosen to correspond toflyable trajectories. A Path can be “re-sampled” at other points intime, resulting in an almost identical Path.

A Dynamical Path is a 5-dimensional entity with x, y, z, and two kindsof time. The two kinds of time are Path Time and Present Time. Path Timeis the time along Path, even though the Path will probably never beentirely flown. Path Time is mostly hypothetical since it's only flownfor sure to the next Delta T. Present Time is the time of where theaircraft actually is. Paths are continuously replanned at each point inPresent Time.

As discussed above, each Path is a 4D entity, with an associated timedimension, but, each DP is composed of a series of Paths generated ateach Delta T by Continuous Replanning. At each delta T, the best Path is(re-)calculated from that point in time into the future. That Path isflown as planned to (only as far as) the next Delta T replanning point.When the aircraft arrives at the next replanning point, a new best Pathis recalculated. Although a Path encodes a plan into the far future, itis only used for one Delta T segment. It's important to plan an entirePath including into the far future, even if not entirely flown. Thisbecause the best next Delta T segment to fly is informed by futureplans. Even if the current Path plan is not flown, it's still the bestplan as far as is known. It's also possible that conditions are stable,so recalculating a Path will result in same Path.

Once flown, the retroactive Path is fixed and immutable (for obviousreasons). At any point in (simulator's) Present Time, only the future ismutable and plan-able, not the past. But a Path spans the entiretrajectory, so a Path includes path and future relative to Present Time.By definition, the points in the past on a Path are the same as thepoints actually flown. The Path is calculated and recalculated tocontinually determine the best Path to fly based on what is known “now.”At the end of a flight, the Path is all in the past, and by definition,is the same as the trajectory. So, as the aircraft moves through PresentTime, history grows in size, and the future shrinks.

A Fleet is a set of all aircraft in the simulation. Note that aDynamical Path is unremarkable in isolation, and a good proxy for realTrajectories in the context of flight planning. Space is the domain ofpossible values of some entity. Path Space is the set of possible flightPaths for a single aircraft. Fleet Path is a set consisting of one Pathfor each aircraft. Fleet Path Space is the set of all possible flightPaths for the Fleet at a particular moment in the simulation. Fleet PathHistory is the Path history for every aircraft in the fleet, i.e., thecontent of the simulation. Path Space History is the set of possibleflight Paths for a single aircraft as its possibilities become moreconstrained.

Paths must avoid each other as well as other objects like storms.Weather Cells are Storms and move over time in both predictable andunpredictable ways and must be avoided. In our computational model, oneor more Weather Cells are introduced and moved within the Air Space.Paths must be dynamically replanned so as to continue to avoid storms(and each other) as storms move. Without this unpredictable element,Paths could otherwise be pre-planned once and for all at departure.

The computation is performed (organized) by software Agents.Conceptually, each Dynamical Path is endowed with “agency.” Agents aresemi-autonomous software code objects acting on their own behalf. Theunit of computation is the Dynamical Path, not the aircraft. It is theresponsibility of each Agent to calculate a new Path plan at eachDeltaT. Agents do their calculations based on available information.Agents do not negotiate per se, but do take into account informationabout other Paths. Agents use Cost Functions to evaluate Path options.Cost Functions quantify issues like separation, fuel consumption, andpunctuality. Optimization is achieved by minimizing overall “costs”associated with a Path. Information Technology issues are not addressedper se by this Dynamical Path system. There are pros and cons with whereto locate computational resources. Computing on board the aircraftreduces latency for replanning, etc., but can increase weight, cost, andother operational considerations. Centralizing computing on the ground,or distributing computing to the aircraft has its own set of tradeoffs.How and where to distribute computing is an ongoing research topic, butnot addressed herein.

Disclosed are a number of novel proprietary algorithms for calculatingDynamical Paths. In principle every Path must be Separated from everyother path. Proximity separation detection is a central consumer ofcomputing resources. In an overly simplistic approach, every Path wouldbe checked for Separation with every other Path. This naïve approachscales in computational difficulty as the number of Paths squared. Thecalculation rapidly becomes impractical: 10000s of Paths would generate100,000,000s checks for separation. An alternative approach is needed;one that scales to very large numbers of Paths.

The disclosed system and technique employs an alternative approach,called Spoxels, or direct analytics. In this approach, candidate Pathsfor separation are winnowed by location. Once the few candidates aredetermined, the closest Path approach is calculated. Closest approach ofCubic Splines can be calculated analytically. This Analytic Separationapproach also scales well to very large numbers of Paths.

In principle, every Path must be separated from every other Path. Once aconflict is detected, the Paths at issue are modified to conform toSeparation rules. In the near future, Separation rules must be adheredto without exception. In the far future, Separation can be morelax—actual Trajectories are still uncertain. In accordance with thedisclosed system, a number of algorithms ensure proper Separationdiscipline. Note that in actual flight, the disclosed system andtechnique may be complemented with other algorithms.

Separation and a number of other factors influence the Trajectories ofaircraft. Paths must be constructed (planned and replanned) to optimizemany competing goals and constraints. These goals can be expressed interms of monetized Cost Functions. Hard constraints like Separation areabstracted as very steep Cost Functions. Soft constraints like on-timearrival and goals like conserving fuel are monetized. The goal is tocompute Paths that lie on the Pareto frontier of cost functions.Deciding relative trade-offs among goals functions are artifacts ofpolicy. Computational modeling is used to explore trade-offs and advisepolicy. The following are some of the issues that must be optimized.Broadly speaking, fuel consumption, on-time arrival, and total operatingcosts, are economic issues.

Paths must be constructed which are flyable and comfortable. This meanslimiting climb and decent rates, turning radii, etc., within guidelinesinvolving passenger comfort and aircraft limitations. Values are drawnfrom actual aircraft performance and policy data derived fromdiscussions with air carrier pilots. These guidelines can be expressedas limits in the allowable accelerations of Paths. Intuitively, this canbe visualized as limits on the “bend” in Paths, which is accomplished bychoosing Path Nodes which conform to these Path limitations. Path isoptimized in consideration and in context of rigid Separation limits, asdiscussed above.

The process of continuous replanning involves, searching for the bestPath among possible Paths. The disclosed system uses a number ofproprietary Search Algorithms. Paths are modeled as if they haveelectrostatic charge. Separation is maintained by Paths repelling eachother. Paths are also repelled by Weather Cells (storms) or exclusionaryairspace.

Paths are dynamically modified toward equilibrium of electrostaticcharge forces. The disclosed system utilizes algorithms for performingthis approach. These algorithms rely on a data structure, describedherein and referred to as “Spoxels”, to identify nearby Paths. As Pathsare modified, Path Nodes are migrated to other Spoxels. Charge Repulsionis performed in the context of economic and other influences on Paths.As mentioned above, intuitively, Paths are dynamically wiggling 4Dstrands of spaghetti.

A population of Path Candidates is generated and evaluated. Thistechnique is reminiscent of genetic algorithms (GAs), but computed inthe continuous domain in the disclosed method. Many candidate Paths canbe considered at once, simultaneously. This approach enables efficientlyexploring the space of many possible Paths. The Graphical Processor Unit(GPU) technology (see below) is particularly efficient at maintaining apopulation of many Paths.

According to one aspect of the disclosure, a method for determining thecapacity of airspace to safely handle multiple aircraft comprises: A)acquiring data describing a plurality of trajectories each representingan aircraft or an obstacle within an airspace, B) recalculating selectedof the trajectories at time intervals; C) identifying conflicts betweenpairs of aircraft trajectories or between an aircraft trajectory and anobstacle trajectory; D) modifying the trajectory one of the pair ofaircraft trajectories or the aircraft trajectory in conflict with anobstacle; and E) repeating B) through D) a predetermined number ofcycles until no conflicts are identified in C), else provide anindication that the airspace is approaching unsafe capacity to handleadditional trajectories

According to another aspect of the disclosure, a method for managingaircraft within an airspace comprises: A) upon entry of an aircraft intoan airspace, receiving from the aircraft and storing in a computermemory data describing a trajectory representing the aircraft; B)periodically re-calculating trajectory; C) identifying conflicts betweenthe trajectory representing the aircraft and another trajectoryrepresenting one of another aircraft and an obstacle within theairspace; D) modifying the trajectory representing the aircraft; and E)communicating data representing a modified trajectory to the aircraft.

According to another aspect of the disclosure, a system for simulationand management of aircraft trajectories within an airspace comprises: A)a network interface, operably connectable to one or more sources of datarelevant to an airspace model; B) a computer memory coupled to thenetwork interface; C) a processor coupled to the computer memory and thenetwork interface; D) an airspace model stored in the computer memory,the airspace model initialized to a plurality of parameters whichcollectively define characteristics of the airspace; E) a plurality oftrajectory data structures stored in computer memory, each trajectorydata structure representing a trajectory to be flown by an aircraftwithin the defined airspace model; and F) a trajectory management serverapplication executable on the processor and configured for: i) acquiringand storing in the computer memory data describing an aircrafttrajectory; ii) periodically re-calculating each trajectory having acorresponding trajectory data structure stored in the computer memory;iii) identifying conflicts between a first trajectory representing anaircraft and a second trajectory representing another aircraft or anobstacle within the airspace model; and iv) modifying the firsttrajectory representing the aircraft.

According to still another aspect of the disclosure, a non-transientmemory apparatus containing a data structure usable with a computersystem for representing an airspace model comprises: a plurality oftrajectories, each trajectory representing a trajectory to be flown byan aircraft within the airspace model, wherein each trajectory ischaracterized by a continuous one-dimensional curve of finite lengthembedded in five-dimensional space-time to find by three spatialdimensions and two time dimensions.

BRIEF DESCRIPTION THE DRAWINGS

The present disclosure will be more completely understood through thefollowing description, which should be read in conjunction with thedrawings in which:

FIG. 1 is a graph illustrating phase transitions and noise;

FIG. 2 is a graph illustrating the results of a prior art traffic phasestudy;

FIG. 3 illustrates conceptually a Five Dimensional Trajectory inaccordance with the present disclosure;

FIG. 4 illustrates conceptually a pair of trajectories in an airspacemodel in accordance with the present disclosure;

FIG. 5A illustrates conceptually a computer architecture for managingaircraft trajectories in accordance with embodiments of the presentdisclosure;

FIG. 5B illustrates conceptually a block diagram representing thearchitecture of a trajectory management engine for managing aircrafttrajectories in accordance with embodiments of the present disclosure;

FIG. 5C illustrates conceptually a computer architecture on board anaircraft for planning aircraft trajectory in accordance with embodimentsof the present disclosure;

FIG. 6 illustrates conceptually a trajectory represented by a set ofcontrol points connected by cubic splines in accordance with the presentdisclosure;

FIG. 7 illustrates conceptually forces acting on location and/orvelocity of trajectory Control Points in accordance with the presentdisclosure;

FIG. 8 illustrates conceptually two adequately separated trajectories inaccordance with the present disclosure;

FIG. 9 illustrates conceptually two trajectories in conflict, i.e. notadequately separated in accordance with the present disclosure;

FIG. 10 illustrates conceptually deconfliction generating Target Pointsin accordance with the present disclosure;

FIG. 11 illustrates conceptually spline-based trajectory physics inaccordance with the present disclosure;

FIG. 12 illustrates conceptually successful deconfliction and resolutionof two trajectories in accordance with the present disclosure;

FIG. 13 illustrates conceptually two conflicting trajectories inspace-time in accordance with the present disclosure;

FIG. 14 illustrates conceptually applying the “force” of elasticity toControl Point in accordance with the present disclosure;

FIG. 15A illustrates conceptually a computer architecture for managingfleets of aircraft trajectories in accordance with embodiments of thepresent disclosure;

FIG. 15B illustrates conceptually a trajectory path traversing an arrayof spoxels in accordance with the present disclosure;

FIG. 16 is a flow chart illustrating an algorithmic process flowperformed by the disclose system in accordance with the presentdisclosure;

FIGS. 17A-C illustrate conceptually the negotiation and management ofreal aircraft trajectories in accordance the present disclosure; and

FIGS. 18-21 are flow charts illustrating algorithmic process flowsperformed by the disclose system in accordance with the presentdisclosure;

DETAILED DESCRIPTION OF THE DISCLOSURE List of Abbreviations andAcronyms

3SAT The Satisfiability Construct for all NP-hard problems

4DT Four Dimensional Trajectories

5DT Five Dimensional Trajectories

ABM Agent-Based Modeling

ANSP Air Navigation Service Provider

AOC Airline Operations Center

ATM Air Traffic Management

ATOP Advanced Technologies & Oceanic Procedures (FAA Ocean 21 Prog.)

ATSP Air Transportation Service Provider

CUDA Compute Unified Device Architecture

DARP Dynamic Airspace Reroute Program

DCIT Data Communications Implementation Team (FAA)

FANS Future Air Navigation System

FMC Flight Management Computer

JPDO Joint Planning and Development Office

NextGen Next Generation Air Transportation System

NAS National Airspace System

PBC Performance-Based Communication

PBN Performance-Based Navigation

PBS Performance-Based Surveillance

RBT Reference Business Trajectory

RNP Required Navigation Performance

RTP Required Time Performance

RVSM Reduced Vertical Separation Minimums

SAA Sense and Avoid

SESAR Single European Sky Advanced Research

TBO Trajectory-Based Operations (of airspace)

UAS Uncrewed Aerial Systems

Disclosed is a system and technique in which individual aircraft flightpath trajectories are assessed on the basis of the future conditionprobabilities, resulting in savings in energy, emissions, and noise,increases the number of fleet seats- or flights-per-day, and a reductionin empty seats- or flights-per-day. A method is disclosed for dynamicmanagement of the performance of multiple aircraft flight trajectoriesin real-time. The computational approach to implementing the system andtechnique is sufficiently fast to work in faster than real-time,enabling predictive powers for managing airspace and fleets. The methodapplies to scheduled or on-demand air transport fleet operations, aswell as to any operation of ground or air vehicle operations ofindividual or fleet makeup. Each aircraft flight trajectory is imbuedwith the mathematical equivalent of an electrically charged string. Thischarged string possesses a mathematical equivalent of an electricalcharge at any point along the trajectory. Such charge is proportional tocertain probabilities associated with the planned flight and plausibledisruptions, as well as to the rules for air traffic conflict,detection, and resolution. These probabilities include measuresassociated with weather, traffic flows, wind field forecasts, and otherfactors. The charged string approach supports the speeds of computationrequired for real-time management of fleets and airspace, contributingwithin a computational and operational system for dynamically managingflight trajectories, to improved economic performance of aircraft fleetsand airspace capacity. The resulting trajectory optimizationcalculations allow for frequent, real-time updating of trajectories(i.e., in seconds or minutes as appropriate to the need), to account forthe impact of disruptions on each flight, based on the primary capitalor operating cost function being optimized (corporate return oninvestment for example). The disruptions accounted for include, but arenot limited to, weather, traffic, passengers, pilots, maintenance,airspace procedures, airports and air traffic management infrastructureand services. The system operates by integrating aircraft flight planoptimization capabilities, real-time aircraft tracking capabilities,airborne networking data communication capabilities, customer interface,and a fleet optimization system. The benefits in fleet performanceexceed the benefits possible only using individual aircraft flight planoptimization systems and methods.

The disclosed system and technique incorporates intent of an aircraft ina natural and computationally efficient way by utilizing conceptsinvolving charged strings, as described herein. More specifically, thedisclosed system and technique accomplishes aircraft trajectorydeconfliction by utilizing objects (“strings”) carrying distributed“charge” to generate repulsive pseudo-forces that cause trajectories tode-conflict. These extended objects represent the trajectory of theaircraft, both the already flown portion and the part in the future thatis available for modification. Since the aircraft is not treated as apoint charge but rather as part of an extended path, moving the aircraftto resolve a conflict involves consistently moving the path that theaircraft is on. This is a better match to optimization procedures thatuse path-based measures (such as overall fuel consumption) to generate afitness measure. The path is constrained in terms of its deformabilityby the physical characteristics and operating limitations of theaircraft, unlike point charge methods that can produce solutions thattechnically de-conflict, but do not necessarily generate flyablesolutions.

In addition, this technique naturally extends to the inclusion of andaccounting for uncertainty. Uncertainty in a 4D representation is anexpanding “cone” of probability about the aircraft's location as afunction of time. Charge can be distributed in higher dimensions thanpoint or line distributions, and pseudo-potential methods offer anatural way of characterizing regions of space-time likely to have alarge number of potential conflicts, even if the individual aircraftpath options are very diffuse. The overlap of a large number of higherdimensional charge distributions will generate high potential just asthe overlap of a large number of one dimensional (precise) chargedistributions will. The difference is that knowing the paths exactlywill generate an exact solution; not knowing the paths exactly willgenerate a description of a space that will require deconfliction in thefuture as information is resolved.

An aircraft 4D trajectory is an extended object in three spatialdimensions plus one time dimension, referred to as a string. In theabsence of other impinging aircraft trajectories, a goal is to achievean optimal solution for a single string, where optimal is defined asminimizing a cost function, often defined as, but not limited to, aweighted combination of total flight time and total flight costs(including fuel burn). Such technique is then extended to scenariosinvolving interacting trajectories combined with uncertainty in spaceand time, potentially for very large numbers of trajectories.

To achieve the dual aims of trajectory optimization while preservingseparation assurance, (the requirement that planes do not fly too closeto each other at any point in their flight path) an aircraft iscomputationally represented trajectory as an electrically charged stringunder tension. If all strings have the same sign of charge, they willrepel each other. This electrostatic repulsion method addresses theissue of overall trajectory optimization which point repulsion methodsdo not, since the point methods do not contain any information about theintent of the aircraft involved (where they are going and what is themost efficient way to get there) and therefore cannot optimize to thatconstraint. The “fictitious forces” generated between the chargedstrings in the trajectory representation will repel the strings enoughso as to ensure aircraft separation, but the counteracting stringtension will ensure the minimum cost trajectory subject to thisconstraint.

Since there is always uncertainty associated with the part of anaircraft's trajectory that has not yet been flown, the future flightpath can be represented as a four-dimensional hypercone with chargedistributed over its volume rather than over the length of a string. Thephysics calculation is not fundamentally altered by changing thedistribution of charge to be over a higher-dimensional object than astring. In addition to calculating fictitious repulsive forces, it ispossible to calculate electrostatic potential fields. Electrostaticpotentials measure the amount of energy required to move objects from aconfiguration of infinite separation to a configuration of proximity,and an electrostatic potential distributed over a region of space-timecan serve as a computational measure for how full the airspace is (orwill be) at a particular point in space and time, even accountingnaturally for uncertainty. This is because many trajectories (evendistributions of trajectory probabilities) impinging on a region ofspace-time will generate a region of high electrostatic potential.Utilizing this approach to phase-transition, it is possible to relateelectrostatic potentials to measures of fullness of the airspace such asthe number and frequency of controlling actions required to fulfillseparation assurance, as explained with reference to the formal problemstatement herein.

Formal Problem Statement

A simple example of a Boolean problem with applications to airspacescience is the following: Consider two aircraft on a head-on collisioncourse. Each aircraft has four “moves” available to it: M_(i)ε{Left,Right, Up, Down} where moves are defined in the ownship frame ofreference. It is desirable to find systemic solutions for the twoaircraft system S₁₂ of the form S₁₂ε{M₁, M₂}. Combinations of individualbehaviors of the two aircraft that produce a systemically unsatisfiedresult are the following:S _(unsat)={(UP₁

Up₂)

(Down₁

Down₂)

(Right₁

Left₂)

(Left₁

Right₂)}.

The other 12 combinations of behaviors constitute satisfactory systemicbehavior. This is an example of an under-constrained problem well to theleft of a phase transition where many solutions are available to thesystem. Additional constraining elements might be the presence of moreaircraft requiring more coordination or the reduction in available movesdue to operational constraints.

In the interest of investigating general phase transition structure inairspaces, the disclosed system and technique utilizes a subset of thevariables which characterize actual real-world airspaces and focuses onenroute trajectories, and simplified aircraft performance to specifiedlimits on speeds and accelerations. In addition, the dynamicaltrajectories have been endowed with agency, acting in concert toautomatically deform themselves according to separation and performancerequirements.

The problem of continuous airspace replanning and deconfliction may berepresented formulaically as follows:

Given the following definitions:

1. 5DT Trajectory Definition

-   -   A trajectory        (        (t, τ); t, τ),        ε        ³ is a continuous one-dimensional curve of finite length        embedded in five-dimensional space-time characterized by three        spatial dimensions and two time dimensions T:(        ³        )→        . Position along a trajectory is parametrized by t and the        current state of all trajectories (see Def. 2) is parametrized        by τ. Because of the extra time parameter associated with the        current state of the system, these are known as “5DT”        trajectories.        2. Airspace Definition    -   An airspace        is a set of N(τ) trajectories {        _(i)(        (t, τ); t, τ), i=1, . . . N(τ),        ε        ³} embedded in five-dimensional space-time (        ³        ) where t parameterizes position along each trajectory        and τ is system (“global”) time.        3. 5DT Time Relations Definitions    -   t, τ: t<τ is “past”, t=τ is “present”, t>τ is “future”        4. Aircraft Position Definition    -   t_(i)=τ defines nominal position of aircraft i along trajectory        _(i)(        (t, τ))        5. Finite-Range Pseudopotential between Trajectory Elements        dT_(i):

${{\phi\left( {{d\; T_{1}},{d\; T_{2}},t,\tau} \right)} = \begin{Bmatrix}{{0\mspace{14mu}{if}\mspace{14mu}{D\left( {{d\; T_{1}},{d\; T_{2}}} \right)}} > d_{c}} \\{{A\left( {d_{c} - {D\left( {{d\; T_{1}},{d\; T_{2}}} \right)}} \right)}^{\alpha}\mspace{14mu}{otherwise}}\end{Bmatrix}},$Where D=distance between trajectory elementsProblem Statement:

Minimize total path length

of all trajectories for each τ: [τ_(i), τ_(f)]

${{\mathbb{L}}_{\min}(\tau)} = {{Min}\left\{ {\sum\limits_{i}{\int{{\frac{\partial{T_{i}\left( {{\mathbb{x}}\left( {t,\tau} \right)} \right)}}{\partial t}}{\mathbb{d}t}}}} \right\}}$

-   -   subject to the following constraints:        Constraints:        1. 4DT Fixed Endpoints of 5DT Trajectories (Endpoints and Flight        Duration Fixed):        T _(i)(t=τ _(init))={        ,τ}_(init) ,T _(i)(t=τ _(final))={        ,τ}_(final),        ε        ³        2. Continuous Deconflicted Airspace State Requirement    -   If |T_(i)(z(t, τ))−T_(j)(z(t, τ))|<vsep, ∥{right arrow over        (T)}(x(t, τ),y(t, τ))−{right arrow over (T_(j))}(x(t, τ) y(t,        τ))∥>hsep for all i≠j and all t, τ such that t_(l)=t_(j). z is        the vertical coordinate of trajectory coordinate T(        (t, τ)), x and y are the horizontal coordinates of T(        (t, τ)). The airspace exists in a deconflicted state as well as        a planned deconflicted state at all system times τ. This        separation specification is a statement of the normal “hockey        puck” separation criterion.        3. Bounded Speed and Acceleration along T_(i)

${{v\;\min} < {\frac{\partial{T_{i}\left( {{\mathbb{x}}\left( {t,\tau} \right)} \right)}}{\partial t}} < {v\;\max\mspace{14mu}{for}\mspace{14mu}{all}\mspace{14mu} t}},i$${{\frac{\partial^{2}{T_{i}\left( {{\mathbb{x}}\left( {t,\tau} \right)} \right)}}{\partial t^{2}}} < {a\;\max\mspace{14mu}{for}\mspace{14mu}{all}\mspace{14mu} t}},i$4. Constants: (vsep, hsep, vmin, vmax, amax, A, dc, a) are all userspecified constantsAssumptions:1. Planning: The Evolution of Trajectories:

-   -   a. As global time τ increases, N(τ) changes as trajectories        enter or leave the airspace system because of initiation or        termination.    -   b. As τ increases, the parts of trajectories characterized by        t<τ become “past” and can no longer change.    -   c. The parts of trajectories characterized by t>τ are “future”        and are subject to continuous replanning until they become        “past”.        2. Acceleration    -   Acceleration bounds are only considered along the trajectory,        perpendicular forces are not considered explicitly.        3. Test Airspace    -   a. The test airspace is a circular region of definable diameter.        Instantiation of Optimization Problem    -   1. Trajectories are approximated by a set of cubic splines        T_(i): T_(i)≅{S_(i,j)(        ,τ,t_(j) ^(final)), j=1, . . . m) where each spline is defined        over a time interval [t_(j) ^(init),t_(j) ^(final)] such that        the union of the time intervals describes the entire trajectory        and the intersection of the splines is a set of control points.        -   a. Positions and velocities are matched at each intersection            of splines, accelerations are discontinuous at intersections            and functions of form at+b otherwise.        -   b. Positions and velocities are independent variables at            each spline intersection point, accelerations are dependent            variables.    -   2. Path integrals over the length of each trajectory are        replaced by cost functions of the form

$C = {\sum\limits_{i = 1}^{N}{\sum\limits_{j = 1}^{m - 1}{{{a\left( S_{i,j} \right)} - {a\left( S_{i,{j + 1}} \right)}}}}}$

-   -   -   Where the a's are accelerations along the trajectory as            defined in Constraints. 3. This minimizes a discrete form of            the first derivative of acceleration, also known as “jerk”.            A cost function of this form is amenable to a local            “smoothing” procedure that is simple and rapid to implement            and is incorporated below in the conflict adapt procedure.        -   The pseudocode sample below is specific to the cubic spline            instantiation of the trajectory deconfliction/optimization            problem.

procedure trajectory optimization/deconfliction( ) begin  initializesystem time: T ← T_(init)  initialize airspace 

 with N(T_(init)) trajectories  repeat   initialize trajectory time t ←T   repeat    for all i, j: i > j     if conflictdetect(T_(i), T_(j), τ)== False,      then next (i, j)     else if conflictdetect(T_(i), T_(j),τ) == True      then conflictadapt(T_(i), T_(j), τ)      ifconflictadapt(T_(i), T_(j), τ) == False       then        returnadaptfailure( )        next (i, j)       else next (i, j)      end if    end if    end for    increment trajectory time t ← t + Δt   until (t== t_(final))   increment system time T ← T + ΔT  until (T == τ_(final))end procedure conflictdetect(T_(i), T_(j), τ) begin  initialize currentstate of trajectories T_(i)(t ≦ τ)  compute time endpoint for trajectorypair t_(max) = Min(T_(i) ^(final), T_(j) ^(final))  initialize t ← τ repeat   if Distance(T_(i)(t), T_(j)(t)) ≦ d_(c)    return {distance,t}   end if   increment planned trajectory time t ← t + Δt  until (t ==t_(max)) end procedure conflictadapt(T_(i), T_(j), τ) begin  computevector between desired and current closest spatial approach  

 ((t, τ))  compute vector between desired and current velocity: 

 ((t, τ))  initialize adjustmentcycle = 0;  initialize adjust( ) = FALSE while (adjustmentcycle ≦ max || adjust( ) !=TRUE) do  begin   computeexponential damping factor$f = \frac{e^{- {adjustmentcycle}}}{\sum\limits_{1}^{\max}e^{- {adjustmentcycle}}}$  increment trajectory closest spatial approach by f 

 ((t, T))   increment velocity at closest approach by f 

 ((t, T))   adjust trajectory velocity and position with smoothingvector

 ((t, T)), f 

 ((t, T)))   if ( accelconstraintsatisfy == TRUE &&velocityconstraintsatisfy == TRUE && separationdistancesatisfy == TRUE)  then adjust( ) = TRUE  end  if adjustmentcycle == max)   returnadaptfailure( ) endSystem Platform and Network Environment

The computer architecture illustrated in FIG. 5A can include a centralprocessing unit 502 (CPU), a system memory 530, including a randomaccess memory 532 (RAM) and a read-only memory 534 (ROM), and a systembus 510 that can couple the system memory 530 to the CPU 502. Aninput/output system containing the basic routines that help to transferinformation between elements within the computer architecture 500, suchas during startup, can be stored in the ROM 534. The computerarchitecture 500 may further include a mass storage device 520 forstoring an operating system 522, software, data, and various programmodules, such as the trajectory management engine 524.

The mass storage device 520 can be connected to the CPU 502 through amass storage controller (not illustrated) connected to the bus 510. Themass storage device 520 and its associated computer-readable media canprovide non-volatile storage for the computer architecture 500. Althoughthe description of computer-readable media contained herein refers to amass storage device, such as a hard disk or CD-ROM drive, it should beappreciated by those skilled in the art that computer-readable media canbe any available computer storage media that can be accessed by thecomputer architecture 500.

By way of example, and not limitation, computer-readable media mayinclude volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for the non-transitory storageof information such as computer-readable instructions, data structures,program modules or other data. For example, computer-readable mediaincludes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memoryor other solid state memory technology, CD-ROM, digital versatile disks(DVD), HD-DVD, BLU-RAY, or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by the computer architecture 500.

According to various embodiments, the computer architecture 500 mayoperate in a networked environment using logical connections to remotecomputers through a network such as the network 599. The computerarchitecture 500 may connect to the network 599 through a networkinterface unit 504 connected to the bus 510. It should be appreciatedthat the network interface unit 504 may also be utilized to connect toother types of networks and remote computer systems, such as a computersystem on board an aircraft 576. The computer architecture 500 may alsoinclude an input/output controller for receiving and processing inputfrom a number of other devices, including a keyboard, mouse, orelectronic stylus (not illustrated). Similarly, an input/outputcontroller may provide output to a video display 506, a printer, orother type of output device. A graphics processor unit 525 may also beconnected to the bus 510.

As mentioned briefly above, a number of program modules and data filesmay be stored in the mass storage device 520 and RAM 532 of the computerarchitecture 500, including an operating system 522 suitable forcontrolling the operation of a networked desktop, laptop, servercomputer, or other computing environment. The mass storage device 520,ROM 534, and RAM 532 may also store one or more program modules. Inparticular, the mass storage device 520, the ROM 534, and the RAM 532may store the trajectory management engine 524 for execution by the CPU502. The trajectory management engine 524 can include softwarecomponents for implementing portions of the processes discussed indetail with respect to the Figures. The mass storage device 520, the ROM534, and the RAM 532 may also store other types of program modules.

Software modules, such as the various modules within the trajectorymanagement engine 524 may be associated with the system memory 530, themass storage device 520, or otherwise. According to embodiments, thetrajectory management engine 524 may be stored on the network 599 andexecuted by any computer within the network 599.

The software modules may include software instructions that, when loadedinto the CPU 502 and executed, transform a general-purpose computingsystem into a special-purpose computing system customized to facilitateall, or part of, management of aircraft trajectories within an airspacetechniques disclosed herein. As detailed throughout this description,the program modules may provide various tools or techniques by which thecomputer architecture 500 may participate within the overall systems oroperating environments using the components, logic flows, and/or datastructures discussed herein.

The CPU 502 may be constructed from any number of transistors or othercircuit elements, which may individually or collectively assume anynumber of states. More specifically, the CPU 502 may operate as a statemachine or finite-state machine. Such a machine may be transformed to asecond machine, or specific machine by loading executable instructionscontained within the program modules. These computer-executableinstructions may transform the CPU 502 by specifying how the CPU 502transitions between states, thereby transforming the transistors orother circuit elements constituting the CPU 502 from a first machine toa second machine, wherein the second machine may be specificallyconfigured to manage trajectories of aircraft within an airspace. Thestates of either machine may also be transformed by receiving input fromone or more user input devices associated with the input/outputcontroller, the network interface unit 504, other peripherals, otherinterfaces, or one or more users or other actors. Either machine mayalso transform states, or various physical characteristics of variousoutput devices such as printers, speakers, video displays, or otherwise.

Encoding of the program modules may also transform the physicalstructure of the storage media. The specific transformation of physicalstructure may depend on various factors, in different implementations ofthis description. Examples of such factors may include, but are notlimited to: the technology used to implement the storage media, whetherthe storage media are characterized as primary or secondary storage, andthe like. For example, if the storage media are implemented assemiconductor-based memory, the program modules may transform thephysical state of the system memory 530 when the software is encodedtherein. For example, the software may transform the state oftransistors, capacitors, or other discrete circuit elements constitutingthe system memory 530.

As another example, the storage media may be implemented using magneticor optical technology. In such implementations, the program modules maytransform the physical state of magnetic or optical media, when thesoftware is encoded therein. These transformations may include alteringthe magnetic characteristics of particular locations within givenmagnetic media. These transformations may also include altering thephysical features or characteristics of particular locations withingiven optical media, to change the optical characteristics of thoselocations. It should be appreciated that various other transformationsof physical media are possible without departing from the scope andspirit of the present description.

Although there are on the order of 2000 IFR aircraft in the NAS attypical peak periods, the systems and techniques disclosed herein areable to simulate several times as many aircraft (>10000) flying enroutetrajectories simultaneously. Simulating large numbers of dynamicallyreplanned aircraft trajectories in faster than real time requiresconsiderable compute power. For ˜100 aircraft, a conventional CPU(multi-core, one machine) computer hardware will suffice utilizing thealgorithms disclosed herein. In order to simulate a complete airspacewith 10³-10⁵ aircraft GPU (Graphics Processor Unit) technology isappropriate. Modern GPUs have greater than 400 computing streams(“cores”) running in parallel on each board. As such, in oneillustrative embodiment, CPU 502 of computer architecture 500 may beimplemented with a GPU 525, such as the Nvidia GTX470 GPU with 448cores, commercially available from NVIDIA Corporation, Santa Clara,Calif. 95050, USA. Using a water-cooled case, three such GPUs may beimplemented in one desktop computer, or about 1350 cores, achieving aperformance of about 2 teraflops at a cost of about $2 per gigaflop.This is more than a thousand times cheaper than a decade ago andcontinues an exponential path that has remained unbroken for 50 years.Within another decade, it is conceivable that this amount of computingpower could reside in an aircraft's cockpit. With a single GPU, theestimated gain is an approximate 100 times performance increase overconventional CPU single-core hardware architecture.

GPUs enable dramatically more computation for modeling assuming thedisclosed algorithms are adapted to the parallel processing paradigm ofthe GPU, a task within the cup competency of one reasonably skilled inthe arts, given the teachings, including the flowchart and pseudocodeexamples, contained herein. The GPU enables millions of softwarethreads, up to 400 plus threads operating simultaneously. Fortunately,thousands of aircraft running simultaneous re-planning algorithms mapsvery well to the GPU parallel processing architecture. A bonus of usingmodern GPUs is advanced graphics, since GPUs were developed for videogame applications. Accordingly, display 106 may be implemented with ahigh fidelity visual output device capable of simultaneously renderingnumerous trajectories and their periodic updates in accordance with thesystem and techniques disclosed herein.

The software algorithms utilized by the system disclosed herein may bewritten in a number of languages including, C#, Python, Cuda, etc. Forexample, the trajectory management system 524, including any associateduser interface therefore may be written in C sharp. High level controlof the GPU, web interface, and other functions may be written in Python.Detailed control of the GPU may be written in Cuda and similar languages(Cuda is a C-like language provided by Nvidia for writing parallelprocessing algorithms). Such algorithms may execute under the control ofthe operating system environment running on generally available hardwareincluding PCs, laptops, and GPUs. For example, as noted above, GPU 525,may be utilized alone, or in conjunction with parallel processinghardware to implement in excess of 1000 cores, enabling a multi-threadedsoftware model with millions of threads of control. Hence, many threadscan dedicated per aircraft Trajectory or Dynamical Path.

FIG. 5B illustrates conceptually a block diagram representing thearchitecture of a trajectory management engine for managing aircrafttrajectories in accordance with embodiments of the present disclosure.In particular, the trajectory management engine 524 may include one ormore executable program code modules, including but not limited to, atrajectory manager 582, a trajectory recalculator 584, a repulsionmodule 586, an elasticity module 588, and a bounding module 590. Thefunctionality of the repulsion module 586, the elasticity module 588,and the bounding module 590 will become apparent in the descriptionsassociated with Figures and the pseudocode examples provided herein.

FIG. 5C illustrates conceptually a computer architecture 578 on board anaircraft 576 for managing aircraft trajectories in accordance withembodiments of the present disclosure. The computer architecture 578illustrated in FIG. 5C can include a processor 571, a system memory 572,a system bus 570 that can couple the system memory 572 to the processor571. The computer architecture 578 may further include a memory 579 forstoring an operating system 581, software, data, and various programmodules, such as the trajectory construction application 583.

The memory 579 can be connected to the processor 571 through a massstorage controller (not illustrated) connected to the bus 570. Thememory 579 and its associated computer-readable media can providenon-volatile storage for the computer architecture 578. Although thedescription of computer-readable media contained herein refers to amemory, such as a hard disk or CD-ROM drive, it should be appreciated bythose skilled in the art that computer-readable media can be anyavailable computer storage media that can be accessed by the computerarchitecture 578.

By way of example, and not limitation, computer-readable media mayinclude volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for the non-transitory storageof information such as computer-readable instructions, data structures,program modules or other data. For example, computer-readable mediaincludes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memoryor other solid state memory technology, CD-ROM, digital versatile disks(DVD), HD-DVD, BLU-RAY, or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by the computer architecture 578.

According to various embodiments, the computer architecture 578 mayoperate in a networked environment using logical connections to remotecomputers through a network. The computer architecture 578 may connectto the network through a network interface unit 573 connected to the bus570. It should be appreciated that the network interface unit 573 mayalso be utilized to connect to other types of networks and remotecomputer systems, such as a computer system on board an aircraft 576.The computer architecture 578 may also include an input/outputcontroller for receiving and processing input from a number of otherdevices, including a keyboard, mouse, or electronic stylus (notillustrated). Similarly, an input/output controller may provide outputto a video display 575, a printer, or other type of output device.

The bus 570 is also connected to specialized avionics 577 that controlaspects of the aircraft 576. In addition, the bus is connected to one ormore sensors 585 that detect and determine various aircraft operatingparameters, including but not limited to, aircraft speed, altitude,heading, as well as other engine parameters, such as temperature levels,fuel levels, and the like.

As mentioned briefly above, a number of program modules and data filesmay be stored in the memory 579 of the computer architecture 578,including an operating system 581 suitable for controlling the operationof a networked desktop, laptop, server computer, or other computingenvironment. The memory 579 may also store one or more program modules.In particular, the memory 579 may store the trajectory constructionapplication 583 for execution by the processor 571. The trajectoryconstruction application 583 can include software components forimplementing portions of the processes discussed in detail herein. Thememory 579 may also store other types of program modules. It should beappreciated that the trajectory construction application 583 may utilizedata determined by one or more of the sensors 585 to assist inconstructing the aircraft's trajectory.

Software modules, such as the various modules within the trajectoryconstruction application 583 may be associated with the system memory530, the memory 579, or otherwise. According to embodiments, thetrajectory construction application 583 may be stored on the network andexecuted by any computer within the network.

The software modules may include software instructions that, when loadedinto the processor 571 and executed, transform a general-purposecomputing system into a special-purpose computing system customized tofacilitate all, or part of, management of aircraft trajectories withinan airspace techniques disclosed herein. As detailed throughout thisdescription, the program modules may provide various tools or techniquesby which the computer architecture 578 may participate within theoverall systems or operating environments using the components, logicflows, and/or data structures discussed herein.

Airspace Model Characteristics

At the most elementary physical level, the airspace consists of air,aircraft and obstacles, e.g. weather cells, closed airspace, etc. In theenroute airspace aircraft trajectories may enter and exit at anyperipheral points on the perimeter of the monitored airspace or fromsomewhere within the geographic area encompassed by the airspace, attheir respective known cruise altitude and headings. Since the intent isto track large numbers of interactions between trajectories, the entryand exit points for each respective trajectory are initially positionedroughly based on the information known about the respective aircraft atthe time of trajectory negotiation or entry into the airspace given itsposition entry an intended destination. The FIG. 4 shows a conceptualairspace model with trajectories of aircraft entering that have beendeconflicted, i.e. deformed to enforce minimum separation.

The airspace provides the context for generating trajectories that areseparated and flyable, if possible. An airspace region or model may becharacterized as “successful” if all trajectories are separated andflyable. If any of the trajectories violate minimum separationdistances, or are not flyable, the airspace may be characterized as a“failed” airspace. A flyable trajectory is defined as one where all thepoints along the trajectory lie within some specified range of speedsand accelerations of the aircraft. This is a proxy for the laws ofphysics, aircraft specifications, and airline policies.

Maintenance of a system of conflict-free trajectories may be managed bymanaging the bulk properties (airspeed, direction, altitude, forexample) of the sets of dynamical trajectories in the airspace, so thata “safe” time/distance was maintained away from the phase boundary. Bulkproperty control in the system means the maintenance of conflict-freetrajectories by keeping a “safe” distance between the current state ofthe system and a phase transition. “Safe” in this context meansmaintaining separation assurance, with conflict-free trajectories,throughout the test airspace. This safe time/distance may be graphed ascomputational iterations required to achieve a conflict-free phasestate, for varying numbers of trajectories, for example. Thistime/distance to the phase boundary can also be increase incomputational intensity, measured in iterations to achieve conflict-freestate. Alternative, the safe time/distance can be considered as thelead-time between present and future conflicted state, measured inminutes.

In addition to endowing the airspace with dynamical trajectories, thedisclosed system and techniques address the large numbers of dynamicaltrajectories in the airspace and analyze all of the dynamicaltrajectories en masse—more like an airspace filled with dynamicaltrajectories, than individual aircraft. In deconflicting a congestedairspace, it is not enough for a solution to exist. It must bediscoverable in time to use it. Hence, the amount of computationrequired to find a solution can be as important as the existence of asolution. As discovered, nearing the phase transition of airspacecapacity is not only a problem with loss of optionality but there is anincrease in the expenditure of computing cycles near this phasetransition. In test airspace, areas approaching a phase transition werecharacterized by reduced planning optionality and an increase incomputing cycles expended in order to maintain minimum specifiedseparation.

The functionality of continuous replanning built into the disclosedalgorithms automatically addresses new separation issues as they arise,and dynamically re-calculated affected trajectories immediately. In thisway storms are handled seamlessly (if they can be handled).

Airspace Density

The behavior of the airspace is a function of aircraft density, flightpath geometries, mixes of aircraft types and performance, and separationminima. Density is defined by the number of aircraft introduced into theairspace and the size and shape (volume) of the airspace. As such, therate of aircraft entering the airspace is dynamic. Density is also usedherein as a parameter in the phase transition analysis metrics. However,since the airspace is non-uniform in its loci of trajectoryinteractions, a more sophisticated method of determining overalldensity, other than calculating the number of aircraft per unit of testairspace is needed. For the density computation, a Gaussian integral,applied to the distance from each aircraft to the measurement point, isused. This provided the probability density of finding an aircraft atthe specified point if the aircraft positions are considered to have anuncertainty specified by a spread parameter. Alternatively, thisapproach measured the density of aircraft weighted more heavily near themeasurement point, which provided a smooth, well-behaved density measurewithout discontinuities. Density units may be measured, for example, inaircraft per 10,000 km.

The presence of phase transitions and the possibility of influencingwhen and where phase transitions occur is affected by modifying thedegrees of freedom for maneuvering by either increasing thedimensionality allowed for deconfliction (allowing vertical maneuvers)or decreasing the separation standard. When the density of the airspacebecame too great, resolving of some conflicts leads to more newconflicts with other trajectories. Under these conditions, conflictswill persist in the airspace, although not necessarily the sameconflicts. Regardless of how many deformation cycles are executed inthese conditions, the airspace will fail to converge to a solution.Although additional processing resolved some of these conflicts, newones appeared, keeping the airspace in a continued roiling unresolvedstate.

In the disclosed system, the negotiated set of trajectories at any pointin time is based on the best available knowledge of all parametersaffecting the difference between the original desired trajectory and thecurrent trajectory parameters. As changes are introduced into thesystem, the effects of these changes are accounted for in the replanningand, once a new plan is selected, a new set of negotiated 4Dtrajectories is established.

The most significant sources of uncertainty include the following:

Convective weather predictions

Wind field predictions

Airport capacity dynamics (as affected, for example, by wind-fieldchanges and the resulting airport configuration)

Maneuvering of other aircraft

The disclosed system and technique represents weather cells (storms) asdynamical obstructions in the airspace. Trajectories automaticallyseparate from these storms—as well as other aircraft. Storms arespecifically designed to have unpredictable trajectories. A set oftrajectories may be fully deconflicted at one point, but as a stormmoves, new conflicts may suddenly arise—either directly from being toonear the storm, or indirectly by the effects of aircraft moving awayfrom storms creating new conflicts with other nearby aircraft.

Trajectory Management Algorithms

The disclosed system and technique utilizes a collection of algorithms,agent-based structures and method descriptions for introducing agency asa methodology for analyzing and managing the complexity of airspacesstates while maintaining or increasing system safety. Described hereinare the plurality of algorithms in the form of pseudocode—with theintent that software engineers can generate actual operational code intheir language of choice for particular custom implementations. The codebelow assumes the programmer has already created the necessaryobject-oriented classes to represent the central abstractions of thisgenre of simulation, namely an airspace, aircraft, and dynamicaltrajectories. As described herein, these trajectories are representedusing Control Points linked together by cubic splines. Otherabstractions are also described below including Target Points, and theirassociated physics-like “forces”, momentum, etc. These classes may beendowed with appropriate state as well as exogenous tuning parameters,the details of which are provided herein.

Although visualizations are immensely valuable in understanding thecomplex dynamics of these algorithms, the pseudocode provided herein isfocused primarily on calculation algorithms, as the algorithms necessaryfor rendering of positional data in near real-time is considered to bewithin the competency of those reasonably skilled within the relevantcomputer programming in light of the teachings disclosed herein, whethersuch calculations utilize a general central processing unit or agraphics processing unit having multiple competing streams or cores. Assuch, no pseudocode for the visualizations is provided here, as thiswill be determined by the size and shape of the actual airspace to bemonitored and given the fact that there are many possible visualizationsone could utilize for this type of task.

The following algorithms are intended to enable tracking of the bulkproperties of large numbers of enroute dynamical trajectories (andassociated aircraft) in arbitrary airspaces. The pseudocode disclosedherein is intended to contain adequate technical detail to enableimplementation in a language of choice on a hardware platform of choiceand is organized by six tasks carried out by these algorithms. Thesetasks are described separately and accompanied by correspondingdescriptions and flow diagrams.

The primary algorithmic tasks for the overall functions of acquiring,managing and displaying trajectories of aircraft within an airspace areorganized into three main high-level tasks, with task number 2containing separately defined sub-tasks, as represented by PseudocodeSample 1 below.

Pseudocode Sample 1 1. Negotiation/Acquisition of aircraft trajectorydata 2. Perform re-calculation cycles on trajectories, using thefollowing sub-tasks: 6 a. Apply repulsion/separation force to closestapproach of conflicting trajectories b. Apply elasticity/smoothing forceto all Control Points on all trajectories c. Apply bounding/limits forceto all Control Points on all trajectories 3. Data analysis and visualdisplay of aircraft trajectories, notification of successful/failedairspace, phase transition structure, etc.

FIG. 16 is a flowchart representing the processes of PseudocodeSample 1. The routine 1600 begins at operation 1602, where thetrajectory management engine 524 first initializes an airspace modeldefined by one or more data structures in memory with one or moreinitialization script. The data variables necessary for defining theairspace model in memory, as well as various parameter values associatedtherewith may comprise, but are not limited to, the followinginformation, any values of which are for exemplary purposes and notmeant to be limiting.

Airspace Data Structure Parameters

1. Airspace Model Identifier

2. Trajectory Count

3. Airspace Dimension Radius

4. vc=530 mph=cruising speed at cruising altitude

5. vmin,vmax=450 mph, 550 mph=speed range at cruising altitude

6. zc=30,000 feet=cruising altitude

7. zmax=42,000 feet=airspace ceiling limit

8. storm.rsep=20 nm=storm/aircraft separation

Trajectory Data Structure Parameters

1. fleet_path_width=64=number of control points per trajectory

2. sim_interval=30.0=simulation heartbeat

3. node_interval=180.0 seconds=time between control points

4. time_scale=60.0=visual simulation time compression factor (simseconds per real second)

5. MetaTime

6. FlightTime

Trajectory Meta-Forces Parameters

1. conflict_buffer_zone=6.0 km=width of zone outside of the conflictzone where repulsion is active and decreasing with distance

2. repulsive_force=0.5=strength of force that increases separation atclosest approach

3. elastic_force=8.0=strength of force that smoothes out trajectories

4. speed_limit_force=2.9=strength of force that moves speed towardcruising speed

5. altitude_force=0.55=strength of force that moves aircraft towardcruising altitude

6. momentum_decay=0.8=proportion of momentum that persists to the nextcycle

7. storm_randomness=0.8=strength of randomizing force that blows stormsaround

Once the airspace model 580 is initialized, from operation 1602, theroutine 1600 proceeds to operation 1604, where the trajectory managementengine 524 acquires trajectory data associated with each aircraftprofile as it enters the airspace. As described above, the trajectorydata and/or aircraft profile associated with each aircraft may comprise,but is not limited to, any of the following information.

Aircraft Identifier

Default Cruise Altitude

Speed

Heading

Destination ID

Airspace Entry Time

Spatial Coordinates

Momentum Buffer

MetaTime

FlightTime

Control Points

Target Points

Confliction Flag

Confliction Trajectory ID

The process of acquiring the aircraft profile and trajectory data foreach aircraft may entail one or more of the process steps outlined withregard to Pseudocode Sample 2 and FIGS. 17A-B.

From operation 1604, the routine 1600 proceeds to operation 1606, wherethe trajectory management engine 524, as well as its constituentsubmodules 582-590, as illustrated in FIG. 5B, performs recalculationcycles on each of the aircraft trajectories 600A-N within the airspacemodel 580. In various embodiments, the trajectory management engine 524may perform recalculation cycles on each of the aircraft trajectoriessimultaneously, or nearly simultaneously. The trajectory managementengine 524 repeatedly perform the recalculation cycles on each of theaircraft trajectories 600A-N, at a frequency defined by heartbeatinterval value currently associated with the airspace model 580.

More specifically, functional algorithms within trajectory managementengine 524 and trajectory manager 582, in conjunction with modules584-590, perform the dual function of 1) “flying” aircraft within anyparticular trajectory, and 2) every delta t of FlightTime, dynamicallychanging the trajectories themselves. The primary clock of using thesealgorithms is in FlightTime (seconds). FlightTime moves forward(incrementally increases in value) as the monitoring and control processproceeds. To “fly” an aircraft (forward), the location and velocity ofan aircraft “flying” a trajectory are calculated by sampling the(appropriate cubic spline of the) trajectory at time FlightTime. Thesevalues determine the current location, speed, and heading of aircraftassociated with an aircraft profile and optionally displayed in anyvisualizations. More importantly, every delta t of MetaTime, thetrajectories themselves are re-calculated (replanned) according tocurrent conditions. Naturally, only the future can be replanned. Thepast is, by definition, frozen to whatever path the aircraft actuallyflew. Additional details regarding performing the recalculation cycleswill be provided with reference to FIGS. 18-21 herein.

From operation 1606, the routine 1600 proceeds to operation 1608, wherethe trajectory management engine 524 performs post-run data analysisproviding any notification and/or a large regarding conflictingtrajectories as well as, in conjunction with GPU 525 presenting a visualrepresentation of one or more of the trajectories within the airspace,as well as any special audio or medical indicia indicating eithersuccessful or unsuccessful deconfliction of trajectories, as illustratedby operation 1610.

Note that, although Pseudocode Sample 1 lists the algorithmic taskslinearly, it will be obvious to those reasonably skilled in the artsthat the tasks for acquiring aircraft flight data and recalculation ofaircraft trajectories, as well as analysis and visualization of thetrajectory data execute continuously following initialization of theairspace model and would be performed with one or more looping tasksdepending on the hardware platform and specific software utilized toaccomplish such tasks.

Spoxel Data Structure

One of the major challenges in monitoring the nation's airspace is theability to monitor and track each aircraft within simulated systemmodel. Particularly challenging is the need for computing trajectorydeconfliction at very high speed because the system ideally isdeconflicting extended objects (trajectories) rather than just havingplanes avoid each other (computationally much easier), a task which mayrequire long and complicated sums and trigonometric calculations andpolynomial root finding that would take too long. The goal was a millionper second.

In order to simplify the calculations associated with each aircrafttrajectory within the system model, a unique technique and datastructure is proposed. Technique comprises mapping the physicalconfiguration of the simulated system (airspace model 580) onto thearchitecture of computer memory 520 such that adjacency is preserved andthat superfast bit manipulation can be used to help in deconflictioncalculations. In order to implement this process, each aircraft isassociated with a new date data structure, termed a “spoxel” 625 whichmay be used to denote four dimensional digital elements in a space-timemodel, as illustrated in FIG. 15B.

If a “ten-minute” equivalent mapping is performed (about the currenttime window for strategic maneuvering), that translates into about 50nautical miles at current jet speeds. Spoxellating the whole US at thisscale (1500 nm×2500 nm) would give 1500 two-dimensional elements. Theten minute resolution would also give 144 elements in a day, and forstarters, we could ignore altitude. This gives 144×2500=360k spoxels.Even going to two-minute mapping resolution (about the scale wherestrategic becomes tactical) gives 45M spoxels, a large number but notunmanageable. Each trajectory T1 of FIG. 15B would produce anidentifying string in a number of spoxels 625 roughly equal to (flightlength)/10, typically about ten. To compute a new trajectory, it is avery fast query to inquire if any spoxel has more than one “mark” in itand then be used to recompute the affected trajectories. This can alsobe extended to immediate spoxel neighborhoods if need be, accounting forcausality.

With the disclosed approach x, y space and time are organized and sortedinto tiles. every path node or control point of every path weretrajectory is sorted into its corresponding “Spoxel” tile. With thisapproach, only path nodes in a Spoxel or nearby need be considered. Notethat the z dimension is not considered separately, so z's will shareSpoxels. This approach trades off memory for computation cycles. SpoxelSize is the size is a function of the granularity of the system. Spoxelx,y size is the x,y separation minimum plus some buffer (e.g. 50%). Thebuffer is so paths attempt to stay farther away than minimum. Spoxelsize in t time dimension is the continuous replanning delta T.

For 5000 km diameter airspace, 10 km separation+buffer, and a delta T of1 min. The number of x, y tiles would be 500 ^2=250K. For 500 minute maxflights, total Spoxels would be 250K×500=125M. With an object size of 4bytes, total memory impact would be 500 M bytes, a memory requirement iswell within the range of current computers.

Trajectory Negotiation And Management

Each trajectory within the airspace model is associated with a uniqueaircraft flying along the trajectory for the duration of its flight. Thedisclosed system and algorithms support multiple heterogeneous aircrafttypes, with varied flight characteristics, including default cruisealtitude, speed, etc. For each aircraft entering the airspace andassociated with a trajectory, a data structure is initialized includingdata parameters associated with aircraft profiles with varied flightcharacteristics, including default cruise altitude, speed, etc. suchdata structures may be stored in a mass storage device 520 of system 500which may be implemented with any of a database in any number of centraldistributed or other database configurations, or something as simple asa spreadsheet form, associated with the either CPU 502 or GPU 525executing the algorithms described herein.

The information and decision flow illustrated in FIGS. 17A and 17B arebased on current data communication systems capabilities. The existingconcepts of operation for TBO developed by the JPDO ([1][2]) provide anational architecture for implementing dynamically interactingtrajectories. However, in the JPDO TBO Concept, distinction is madebetween strategic and tactical trajectory changes. In the disclosedsystem and techniques, strategic and tactical considerations areconsidered together, seamlessly. It is possible for the 5DT trajectoryoptimization function to account for the constraints in the airspace asit optimizes the trajectory of an aircraft and then has that trajectorysent to an aircraft via the data communication systems in use today.

As illustrated in FIGS. 17A-C, the underlying TBO trajectory negotiationbetween aircraft 576 and network interface unit 504 of system 500 maycomprise the following six step protocol:

-   -   1. 5DT₁ Reference Business Trajectory AS FILED—ATSP/AOC computes        5DT₁, (AKA Reference Business Trajectory—RBT), optimized against        available own-fleet, airspace and business constraints        information. The ATSP/Dispatcher files this 5DT, which serves as        the “Reference Business Trajectory,” or the best business case        flight plan for the operator/ATSP=Air Transportation Service        Provider, for time at 5DT₁ minus X minutes (X=time from flight        plan filing to taxi).    -   2a. 5DT₁—AS AUTHORIZED—ANSP computes 5DT₂, optimized against        available airspace and business constraints information at        time=2. The ANSP sends 5DT₂ to the Flight Deck, which serves as        the initial airspace-case flight plan.    -   2b. Copy of 5DTi—AS AUTHORIZED—ANSP computes 5DT₂, optimized        against available airspace and business constraints information        at time=2. The ANSP sends a copy of 5DT₂ to the ATSP, which        serves as the best airspace-case flight plan for the ANSP.    -   3. ATSP Re-computes 5DT_(i)—ATSP re-computes 5DT_(i), optimized        against ANSP-provided changes from 5DT₁. If no replanning is        required, ATSP accepts changes. If another renegotiation between        the ANSP and ATSP were required, then the ATSP-ANSP cycle would        produce 5DT₃, for example.    -   4. 5DT_(i)—Requested/Cleared—The Flight Deck manages 5DT_(i),        including maneuvering within airspace safety and business policy        criteria. Flight Deck identified change requests are sent to        ANSP. If changes are acceptable to ANSP, ATSP is notified        through copy function (Step 2b).    -   5. 5DT_(i) is Re-computed—Requested changes can be sent to        Flight Deck then on to ANSP or from Flight Deck to ATSP then on        to ANSP    -   6. 5DTi AS FLOWN—Aircraft location on 5DT; is communicated to        ATSP, where 5DT_(i+1) is replanned (optimized) against available        constraints. As required, the ATSP requests updated 5DT_(i+1),        based on business criteria, and the cycle repeats with Step 1.        5DT Trajectory Theory

Prior to reviewing the algorithms necessary for recalculation oftrajectories, it is appropriate for some background discussion oftrajectory theory and trajectory transformation in light of the airspacemodel context. At the most elementary physical level, the airspaceconsists of air, aircraft and obstacles, e.g. weather cells, closedairspace, etc. However, since aircraft move over time, the disclosedsystem and technique represents the dynamical moving aircraft with theabstraction of trajectories, which are more useful in representing manyissues in airspace design and management. Still further, the system andtechnique handles such trajectories as dynamical entities which arecontinuously (in practice, every small discrete Δt) re-calculated(replanned) while an aircraft is in flight as required by thecombination of an interacting system of trajectories combined with anevolving system of constraints, such as weather or unforeseen flightalterations, which can emerge over time.

With such abstraction of dynamical trajectories and adaptive replanning,comes two time parameters for consideration. The first is the timeendemic to the passage of origin-to-destination time withintrajectories, namely flight time (FlightTime variable in our algorithms,as described herein. Second, there is an additional meta time (MetaTimevariable) over which the trajectories themselves change. Such timevariables may be seen as “from” time and “to” time and the state of theairspace at a given future time may change depending on what time it isbeing computed and forecast from, as new information is constantlyarriving.

FIG. 3 illustrates conceptually a Five Dimensional Trajectory (5DT,three position variables plus current time and future time variables).Over time, the trajectory itself is deformed according to physics-like“forces” exerting pressure on the trajectory, thus changing its shape.The deformation might be to achieve minimum separation or to avoidweather.

Trajectories

Conceptually, dynamical trajectories are abstractions spanning bothspace and time. Hence trajectories are 4DT, i.e. 4 dimensional locationand one time dimension. However, due to the exigencies of airspace,trajectories may need to be replanned dynamically. In the disclosedalgorithms, at every delta t time increment, all the trajectories arereplanned (re-calculated) according to current conditions and are. quitedynamical. In the disclosed system and technique, 4DT Trajectory itselfis considered a dynamical entity, replanned every delta t, whichproduced two types of time. There is the flight time embedded into everyinstance of a trajectory. Every trajectory also changes itself over timeso, an additional MetaTime variable is included, which gave eachtrajectory 5 dimensions (3 dimensional location plus 2 timedimensions—FlightTime and MetaTime.

Intuitively, a single trajectory instance is like a hard strand ofspaghetti lying still on a cold plate—whatever curve it has isstatically fixed in place. A collection of dynamical (suite of changing)trajectories is like a soft strand of spaghetti curling, stretching, andmoving away from other strands of spaghetti in a pot of boiling water.Over the course of its flight time, an aircraft might fly parts of manydynamically replanned trajectories. An actual flown flight path is, ineffect, pieced together from many instances of trajectories as thedynamical replanning process re-shapes the trajectory in MetaTime,responding to maintain separation or avoid weather.

The concept of 5DT is illustrated with the airspace model 400 of FIG. 4in which a trajectory itself is modified. The future of any particulartrajectory has a FlightTime associated with it. In addition,trajectories are modified at some time t in MetaTime as well.

Trajectory Generation and Deconfliction

Typical optimal long-range vertical profiles for commercial jettransport aircraft consist of optimal ascent and descent segmentsconnected by a long cruise-climb or step-climb segment. Optimalhorizontal routes are not as easy to compute because the variations inthe wind field lead to a non-convex nonlinear optimization problem withpotentially many regions of local minima. As a result, approximateoptimization solution approaches must often be considered even beforethe added complexity of deconfliction is factored in.

In order to generate dynamic optimization (continuous replanning) anddeconfliction of thousands of trajectories and observe realisticemergent collective phenomena, a number of algorithmic accelerations areemployed. The disclosed system and techniques utilize scalableheuristics based on pseudo-potential methods to achieve rapid systemicdeconfliction. To incorporate intent and optimize path dependentmeasures, such as time and fuel burn, a concept from theoreticalparticle physics, the notion of an ensemble of interacting extendedobjects (‘strings’) is employed. Such extended objects are identifiedwith two candidate 4D aircraft trajectories T1 and T2, depicted inairspace model 400 of FIG. 4. Strings are endowed with a distributedpseudopotential so that they repel each other, an extension oftraditional pseudopotential methods where the objects themselves repeleach other, and the charge is sufficient such that required separationis maintained. In FIG. 4, aircraft trajectories T1 and T2 are endowedwith repulsive pseudopotentials. The circles represent time slices inthe predicted future. Separation is maintained by the pseudopotentialdeforming the strings, which distribute the deformation along theirlength so as to reduce curvature to acceptable levels.

Initial Trajectories

By convention, the altitude of the endpoints of every trajectory is thedefault cruise altitude of the particular aircraft flying the trajectoryat the time it either enters or exits the monitored airspace.

The velocities of trajectories at the entry and exit points at the edgeof the airspace have direction as known at the time of entering and amagnitude equivalent to the default cruise speed of the associatedaircraft. These entry and exit points can be from the departure airportgate to the arrival airport gate, including all moving of the trajectoryon the ground, to takeoff, to the landing, surface movement, and arrivalat the destination airport gate. Alternatively, the entry and exitpoints can be anywhere along the trajectory, during cruise for example,and from the top of descent to the arrival point on the destinationairport.

Once the aircraft profile for each and aircraft entering the airspace isacquired, an initial trajectory path is created in the form of a cubicspline connecting the entry and exit points of the airspace. Since entryand exit points are likely offset from one another, trajectory pathswill likely be curved, following the shape of the cubic spline.

Cubic Splines

In the disclosed system and techniques, cubic splines are usedextensively in representing trajectories here, as well as in all of thecalculations of forces applied to trajectories to move and modify them.A natural way of representing curves is with polynomials, which have theconvenient property that they are easily differentiable for ease ofinter-calculating locations, velocities, and accelerations. In addition,polynomials are computationally efficient.

For trajectories, the location and velocities of both end points areencoded into the polynomials. Hence, a third degree (cubic) polynomialis used. Once defined, any point along a cubic spline can be quicklysampled for location, velocity, and acceleration.

The use of control points for cubic splines in graphics applications isknown, however, the control points utilized herein are different, inthat graphics applications typically use four control points to defineeach segment. The system and techniques disclosed in utilize cubicHermite splines, which are defined by two control points with velocityas well as position, and all control points are on the trajectory. Acontrol point is simply the position and velocity of the desiredtrajectory, sampled at a specified time. is difference is due to theinterest in time and velocity, which is not shared by graphicsapplications.

Control Points—Representing Complex Trajectory Path Shapes

Although trajectories are initialized as simple cubic splines connectingentry and exit points on the perimeter of the airspace, as trajectoriesneed to deform to maintain separation from other trajectories, they willneed to take on more complex shapes.

In order to represent arbitrary complex curved paths though theairspace, trajectories are endowed with “Control Points”, spacedregularly in time, one Control Point every delta t (DeltaFlightTime)along the entire trajectory path. Control Points are connected togetherwith cubic splines.

Hence trajectories are actually a set of many cubic splines, connectedtogether via Control Points. Although the initial trajectory iscalculated as a single cubic spline connecting the entry and exit pointsof the airspace in a single graceful curve, in fact, this single splineis sampled at each time t of each of the Control Points of thetrajectory, and the full cubic spline trajectory is re-represented as aset of cubic splines. Once represented in this compound spline fashion,it's still the same curve, but has much more flexibility to be deformedas forces are applied to it later in the process.

Below FIG. 6 shows a single arced cubic spline represented as 9 shorter(almost linear) cubic splines, connecting 10 Control Points. (The yellowControl Point marks the beginning Control Node at the entry to theenroute airspace.)

Although in principle trajectories may have an arbitrary number ofcontrol points, in a disclosed embodiment, for illustrative purposesonly, implementations of these algorithms use Control Points to 64 pertrajectory. So, for example, with a 1000 km wide hypothetical airspace,can have about one Control Point per minute of Flight Time.

As described above, Control Points are used to represent and define thepath of a trajectory. A trajectory consists of one Control Point foreach delta t of its path. Control Points are connected together by cubicsplines.

In an illustrative embodiment, Control Points may be represented by 7double-precision values:

-   -   Time, in seconds, in Flight Time—constant    -   3 x-y-z spatial coordinates, in kilometers    -   3 x-y-z velocities, in km/sec

When a trajectory is altered (changed to a different trajectory), thevalues of one or more Control Points are changed. In particular, aControl Point can be changed by revising the values of the spatialand/or velocities. Note that the Flight Time associated with the ControlPoint is immutable, i.e. is a constant.

5DT with Replanning

Conceptually trajectories are abstractions spanning both space and time.Hence trajectories are four dimensional entities—one temporal and threespatial dimensions. However, due to the exigencies of airspace,trajectories may need to be replanned dynamically. In the disclosedalgorithms, at every delta t time increment, all the trajectories arereplanned (re-calculated) according to current conditions. Thecalculation may or may not actually result in changed paths. But ifneeded, trajectories will be re-shaped by altering one or more ControlPoints on the trajectories. Trajectories managed by these algorithmsdescribed here are quite dynamical.

Every 4DT Trajectory is itself a dynamical entity, replanned every deltat. Hence there are two types of time. There is the Flight Time embeddedinto every instance of a trajectory. But a trajectory itself changesover time. So there is an additional Meta Time as these 4DT trajectoriesthemselves dynamically change over time.

In this sense, dynamical trajectories are abstractions spanning spaceand two types of time. Hence these dynamical (suites of altered)trajectories are conceptually five dimensional entities—two temporal andthree spatial dimensions.

Over the course of its Flight Time an aircraft might fly parts of manydynamically replanned trajectories. An actual flown flight path is, ineffect, pieced together from many instances of trajectories as thedynamical replanning process re-shapes the trajectory in Meta Time,responding to separation, etc.

The concept of 5DT is illustrated in FIG. 3 where a trajectory itself ismodified. The future of any particular trajectory has a FlightTimeassociated with it. In addition, trajectories are modified at some timet in Meta Time as well. In FIG. 3 an original trajectory (blue),possibly modified to detour around some obstacle at some time t in MetaTime, thus generating modified trajectories. Each trajectory and itsassociated Control Points have time variables in Flight Time. Inaddition, these trajectory modifications occurred at some differentflavor of time t in Meta Time.

Deforming Trajectories

The values of Control Points are informed by applying physics-likeforces to the trajectories, producing Target Points for moving ControlPoints. In the algorithms for applying specific forces detailed below,all of the forces calculate some Target Point goal—regardless of howeach force makes its specific calculation. The lingua franca for allforces is to calculate one or two Target Points per application of theforce, which then directs the universal deformation machinery, describedbelow. This simplifies and reduces the process of generating forces toonly calculating Target Points. Once a Target Point is calculated, it ishanded off to the general dynamical functionality for actual movement ofthe Control Points (change their positions and velocities) according tomultiple forces acting simultaneously on each Control Point

Moving Toward Target Points

Rather, than wholesale moving Control Points to these Target Points, theControl Points are instead moved toward the target goals incrementally.More precisely, these forces act to change the acceleration of a ControlPoint in some specified direction, causing it to eventually arrive there(or even beyond)—unless of course it is pulled in other directions byother forces. The actual effect of many of these physics-like forcesacting in concert is to generate a constellation of effects on ControlPoints (more precisely accelerations on Control Points in MetaTime)toward various Target Points, which are summed and applied in aggregateto each Control Point. Hence the Control Points move in carefullycoordinated ways, bottom up from the forces applied, thus deforming thetrajectories toward the macro goals of separation and efficient flyableflight paths.

Magnitude of Force Effects

Once a Target Point is identified by applying a force, the effect of theforce is calculated as the difference between the current location ofthe point and the location of the Target Point. Differences arecalculated in all 6 spatial dimensions of the Control Point—x y zposition and x y z velocity. Such differences are multiplied by aconstant and are then added to the Momentum Buffer. The effect is toimplement a dynamic similar to Hooke's Law (F=−kx), where the fartheraway from the goal, the larger the force (and acceleration) towards thegoal. In the case of separation, a sigmoid function is applied to theotherwise linear force, centered at minimum separation. As such,repulsion is applied up to the safety margin, but is significantlystronger below minimum separation. Accordingly, even a single separationviolation is given increased importance (and acceleration in MetaTime),resulting in much quicker resolutions of airspaces, which if solvable,converge to zero conflicts quickly. FIG. 7 shows Control Point beingmoved according to current forces. Note that both location and velocitycan be affected.

Re-Calculation Cycles

The primary rhythm of the dynamical airspace described here is togenerate dynamically changing trajectories, one cycle every delta t inMetaTime. There can be arbitrarily re-calculation event along atrajectory. From the point of view of an aircraft, limited only byavailable computation cycles, there can be one trajectory re-calculation(replanning) cycle carried out every few seconds of Flight Time. Hence,in practice, this process of many re-calculations per aircraft enrouteflight approximates continuous replanning of the aircraft's trajectorywhile it is flying. The system attempts to carefully deform thetrajectories such that separation is enforced, and the paths are alwaysflyable (i.e. velocity and acceleration limits are maintained).

Deformation (Sub-) Cycles

A secondary rhythm occurs within each re-calculation cycle. Multiplesteps or sub-cycles are required to properly deform the currenttrajectory so as to respond to current pressures and urgencies (e.g.separation exigencies). In each deformation cycle, the trajectories aregradually and incrementally changed. All the deformation cycles takentogether within a single larger re-calculation cycle may have a verylarge impact on trajectories, depending on the pressures at that momentin the aircrafts' journeys. These “pressures” are physics-like “forces”of repulsion, elasticity, etc., are applied to the trajectories. Beforea re-calculation cycle, a trajectory has some set of Control Pointvalues. After the re-calculation cycle, the Control Points may have newvalues, and, in effect, be a new trajectory). At this level of detail,the 7 values described above are necessary and sufficient forrepresenting Control Nodes. However, during the re-calculation processitself, an additional state is required to coordinate the gradualdeformation of the trajectories over many deformation cycles.

Momentum Buffer

The additional state needed to coordinate deformation is stored in theMomentum Buffer. Momentum, as implemented here, enables continuallymaintaining near-optimal trajectories over the course of entire flights.The purpose of deformation cycles is to iteratively calculate theunderlying dynamics required to ‘glide’ or translate the trajectoriesinto new positions in the airspace. This dynamic movement requires thatthe successive deformation cycles be tied together into one (apparently)continuous movement, guided by local pressures. This dynamical ‘gliding’process is analogous to momentum (with friction) in physics. To linkdeformation cycles together to accomplish (apparently) continuousmovement of trajectories, additional state is needed to augment thestate already contained in the Control Points. This is captured in theMomentum Buffer, which stores the current state of dynamic movement ofeach Control Point. Using the principle of inertia, if a Control Pointis moving in a given direction, the Momentum Buffer will enable it tokeep it moving in that way, modulo friction.

For every Control Point, there is exactly one Momentum Buffer. It hasthe same structure as a Control Point with the exception of no need torepeat Flight Time (which is a constant in a Control Point). A MomentumBuffer has the following structure:

-   -   3 x-y-z spatial coordinates in kilometers    -   3 x-y-z velocities in km/sec (seconds in Flight Time)

As stated above, the purpose of the Momentum Buffer is to provideinertia to the trajectory Control Points during the deformation process,so forces on trajectories continue to have their effect over subsequentdeformation cycles. For example, if part of a trajectory is beingrepelled by another entity (another trajectory, weather cell, etc.), thetrajectory receives an initial push (acceleration in MetaTime) from theforce of repulsion. With momentum functionality built in to thisprocess, the initial push continues to push on the trajectory, evenafter that deformation cycle—into subsequent deformation cycles.Visually, this has the effect of trajectories gracefully gliding awayfrom each other.

In addition to momentum, there is also a notion of friction. Momentum isattenuated every deformation cycle, thus gradually reducing the effectof previous accelerations applied to Control Points. Hence, trajectoriesglide to a stop in the absence of applications of new forces.Algorithmically, each Momentum Buffer accumulates the effects of themultiple forces acting on a Control Point, when they are then added tothe values of the Control Point at the end of each deformation cycle.The Momentum Buffer retains its values across deformation cycles,although they are attenuated every cycle, resulting in an exponentialdecay of the original force.

Re-Calculations of Trajectories

Pseudocode Sample 2 below corresponds to task of performingre-calculation cycles on trajectories.

Pseudocode Sample 2 1. Run the trajectory initialization script 2.Initialize all the Momentum Buffers to zero 3. Repeat the followinguntil the end of the simulation a. Repeat until deconflicted or maximumre-calculation cycles exceeded i. If maximum iterations exceeded: 1.Note separation failure 2. Either continue, or exit depending onpreferences ii. Collect enumeration of all pairs of conflictingtrajectories iii. Apply Forces to Momentum Buffers (generating TargetPoints) 1. * Apply repulsion/separation force to closest approach ofconflicting trajectories 2. * Apply elasticity/smoothing force to allControl Points on all trajectories 3. * Apply bounding/limits force toall Control Points on all trajectories iv. Add the effect of each forceto its corresponding Momentum Buffer v. Apply Momentum to trajectories(according to target points) 1. Add each Momentum Buffer to itscorresponding Control Point, component by component 2. Control pointswill have moved (changed location and/or velocity) some (small) amountwhere the Momentum Buffers were non-zero vi. Attenuate Momentum Buffers(analogous to applying friction) b. Fly aircraft forward one simulationtime step (note: this is not one Control Point) by adding delta-t to thetime value of aircraft, and sampling each aircraft's trajectory at thisnew time. (See section above on “Pseudocode: Flying Aircraft”) c. Recordmeasurements (density, number of conflicts, etc) d. Update visualization4. Store data for later analysis

FIG. 18 is a flowchart representing a process for managing trajectoriesof aircraft within an airspace. A routine 1800 begins at operation 1802,where the trajectory manager 582 retrieves momentum buffers for eachtrajectory within the airspace. Momentum buffers are storage locationswhere the current state of dynamic movement of each control point isstored. A momentum buffer as well as other data structures associatedwith an aircraft trajectory are initialized upon negotiation of thetrajectory at the time of the aircraft entering into the airspace model.In various embodiments, the momentum buffers are capable of storing thethree x-y-z spatial coordinates and 3 x-y-z velocities. From operation1802, the routine 1800 proceeds to operation 1804, where the trajectorymanager 582 retrieves trajectory data associated with each aircraftwithin the airspace. From operation 1804, the routine 1800 proceeds tooperation 1806, where the trajectory calculator 584 performsrecalculation cycles on all trajectories. In various embodiments, therecalculation cycles may comprise computing at least one of therepulsion, elasticity, bounding forces that are acting on thetrajectories, utilizing repulsion module 586, elasticity module 588, andbounding module 590, respectively, under the direction of trajectorycalculator 584.

From operation 1806, the routine 1800 proceeds to operation 1808, wherethe trajectory manager 582 identifies pairs of conflicting trajectories.In various embodiments, the trajectory manager 582 identifies pairs ofconflicting trajectories by determining the separation distance betweenthe trajectory of an aircraft and the trajectories of the other aircraftwithin the airspace. If the separation distance between the trajectoryof an aircraft and a particular trajectory of another aircraft withinthe airspace is less than a predetermined separation minima associatedwith the airspace model, the trajectory manager 582 identifies the twotrajectories as conflicting, including any audio or visual alarms andnotifications associated with presentation of airspace data. Fromoperation 1808, the routine 1800 proceeds to operation 1810, where thetrajectory recalculator 584 applies forces to momentum buffersgenerating target points. In some embodiments, the trajectoryrecalculator 584 may apply at least one of the repulsion, elasticity,bounding forces to aircraft trajectories within the airspace. As aresult, target points are generated that correspond to a vector towardswhich the trajectory is directed from the last known control point.

From operation 1810, the routine 1800 proceeds to operation 1812, wherethe trajectory recalculator 584 adds the effect of each of the forces orinfluences to the corresponding momentum buffer. From operation 1812,the routine 1800 proceeds to operation 1814, where the trajectoryrecalculator 584 applies momentum to trajectories. A momentum buffer aswell as other data structures associated with an aircraft trajectory areinitialized upon negotiation of the trajectory at the time of theaircraft entering into the airspace model. It should be understood thatalgorithmically, each momentum buffer accumulates the effects of themultiple forces acting on a control point, when the forces are thenadded to the values of the control point at the end of each deformationcycle. The momentum buffer retains its values across multipledeformation cycles, although the values are attenuated every cycle,resulting in an exponential decay of the original force. The momentumbuffers are attenuated to simulate frictional forces that may be actingon the aircraft. The momentum buffers are initialized to zero for eachnew 5DT calculation. That is, as the aircraft all move forward onedelta-t quantum of time, the entire airspace is recalculated at the newinstant of simulated clock time. At such point in time, just before afull airspace recalculation is begun, all the momentum buffers areinitialized to zero. The only history retained from the previousrecalculation of the entire air space are the trajectory pathsthemselves (which may now get modified). Since every node for everyaircraft trajectory has a momentum buffer, all of these buffers areinitialized to zero at the beginning of this recalculation of the entireairspace. The re-calculating of the entire airspace takes a number ofiterations. This takes computer time, but no time in the sense of “5DT”time, referred to as (regular time clocks-stopped) computer time “metatime”. At each cycle of meta time, the momentum buffers are NOTre-initialized to zero. Rather, they retain an (exponentiallyattenuated) history of the results of previous meta cycles. Hence a“push” from a previously applied force (in previous meta time) stillkeeps pushing some amount in subsequent cycles, e.g. like a billiardball keeps rolling even after the first shove, but gradually slows downtoo. To that extent, the trajectory nodes are like billiard balls whichget pushed and shoved by a myriad of forces applied on them, and thenslowly come to an equilibrium as trajectories assume mutually agreeable(separated, smooth, etc.) paths.

From operation 1814, the routine 1800 proceeds to operation 1816, wherethe trajectory recalculator 584 samples aircraft trajectory at aircraftflight time (t+δt). From operation 1816, the routine 1800 proceeds tooperation 1818, where the trajectory manager 582 records measurementsbased on new aircraft trajectory flight time. In various embodiments,these measurements may include any of density, number of conflicts, etc.From operation 1818, the routine 1800 proceeds to operation 1820, wherethe trajectory management engine 524 in conjunction with GPU 525presents updated aircraft trajectories and updates visualization viadisplay 106.

Trajectory Deformation Forces

The Pseudocode Samples 1 and 2 provide a complete description of thecontrol algorithms, including acquisition of each aircraft data withinthe airspace and data recalculation trajectories, however, there isstill additional pseudocode needed apply physics-like ‘forces’ to thetrajectories to deform them appropriately. These (sub-) tasks are:

-   -   a. Apply repulsion/separation force to closest approach of        conflicting trajectories    -   b. Apply elasticity/smoothing force to all Control Points on all        trajectories    -   c. Apply bounding/limits force to all Control Points on all        trajectories

Such subtasks are achieved utilizing the algorithms defined inPseudocode Samples 3-5 herein which should be reviewed within thetheoretical background set forth below.

Trajectories would remain unchanged if there were no pressures to changetheir paths. In a sparse airspace, initial trajectories can be quitestable with no need to change already optimal trajectory paths. However,in more dense airspaces, separation may force changes in paths—typicallylengthening the paths to go around some obstacle. On the other hand,economic pressures will tend to force the path to be more evenly curved,to save fuel, fly more smoothly, etc. In addition, physical limits onvelocity and acceleration will tend to force the path into more flyableshapes as well. The shortest possible path may not be flyable. Inprinciple, our algorithms search for shortest flyable de-conflictedpaths (modulo issues around local minima, etc.)

These practical requirements for trajectories can be conceptualized andimplemented as physics-like ‘forces’ thus simplifying the problem, aswell as simplifying the algorithms used to deform the trajectories. Asnoted, the disclosed algorithms support three types of ‘forces’ that actto deform trajectories, including: Repulsion and Elasticity andBounding. For every deformation cycle, the three forces above areapplied to some or all of the Control Points, depending on the type offorce:

-   -   Repulsion—only on closest approach of pairs of conflicting        trajectories    -   Elasticity—on every Control Point    -   Bounding—on every Control Point

As described above, the result of applying a force is not to move aControl Point per se. The effect of a force is simply to contributeeffects (more precisely accelerations in Meta Time) to Control Points,implemented in the algorithms as adding values to the Momentum Buffers.

Maintaining minimum (safe) separation between trajectories is arguablythe most important constraint of the trajectory replanning process.Rather than doing conflict detection and resolution per se, the innatecharacter of the trajectory strings or tubes is that they repel eachother in such a way as to be always in a state of separation.

This method of separation is possible because entire trajectories areseparated (throughout their entire length), as opposed to separatingaircraft per se. In effect, there are no surprises postponed into thefuture except when new conditions arise, for example, changing weatherconditions. Even then, entire trajectories are once again immediatelyand fully separated through the operation of repulsion.

The most complex force to apply is repulsion, because it is only appliedconditionally—that is, only when conflicts are detected among pairs oftrajectories. The process is additionally complex because conflictsthemselves must be detected dynamically for each deformation cycle.

New conflicts may arise for a trajectory resulting from de-conflictingsome other pair of trajectories. In addition, weather cells may movebetween one re-calculation cycle and another, generating new conflictswith the storm, reverberating to new conflicts between other previouslydeconflicted pairs of trajectories.

Conflict Detection

One function of the Trajectory manager 582 is, at the beginning of eachdeformation cycle, the repulsion algorithm requires an enumeration ofthe set of all pairs of trajectories that are currently in conflict—andif conflicting, the algorithm needs to know the precise points ofclosest approach for each trajectory.

The simplest algorithm for this is to exhaustively search all possiblepairs of trajectories, for those for which the closest approach is lessthan the minimum allowed separation. There is no simple analyticexpression for the closest approach of two cubic splines. However, anumerical approximation is fast and practical. In the disclosed systemand techniques, the algorithms sample the cubic splines at a granularityof 32 samples between each pair of Control Points.

The simple exhaustive algorithm for conflict detection described abovescales as the square of the number of trajectories. Hence, for largenumbers of trajectories, optimizing the conflict detection algorithmbecomes a priority. There are a number of candidate optimizationalgorithms. The most straightforward approach is to ‘tile’ the 4DTspace, and annotate the tiles with all the control points that fallwithin corresponding tile areas. Since control nodes tend to moveslowly, so the content of the tiles is fairly stable, this approach isquite efficient, scaling linearly with the number of trajectories.

Repulsion/Separation Algorithm

Rather than doing conflict detection and resolution per se, thetrajectory strings or tubes were designed to repel each other in amanner that always maintains required separation. This method ofseparation was possible because entire trajectories were separated(throughout their entire length), as opposed to separating individualaircraft. In effect, no surprises are postponed into the future, unlessnew conditions arise, for example, changing weather conditions. Eventhen, entire trajectories are again immediately and fully separatedthrough the operation of repulsion.

The purpose of applying the repulsion force to a trajectory is purely togenerate Target Points that can be turned into changes on Control Pointsas described above. This section describes how separation encountersgenerate Target Points.

In the disclosed algorithms, an arbitrary value notion of minimumseparation is used (e.g. 5 nm). In addition, the notion of a “margin” ofseparation is added (e.g. 2 nm). When a conflict is found, the disclosedalgorithms use a separation goal of minimum separation plus an extramargin (e.g. 5+2=7 nm). This policy enforces extra safety while guardingagainst some potential oscillations at the boundary of the separationminimum. Hence the Target Point is constructed based on this moreaggressive separation distance, including the margin.

FIG. 8 illustrates two trajectories T1 and T2 within airspace model 400that are adequately separated. The two trajectories T1, T2 are just atthe minimum desired distance apart including the less dark margin EM.The trajectories are illustrated with control nodes marked as points.Separation minimum SM (e.g. 5 nm) is displayed darker, with the extramargin EM displayed less dark. In this case, there is no separationissue, so no repulsive force need be applied.

FIG. 9 illustrates conceptually a separation conflict. The trajectoriesT1, T2 are too close to each other, indicated by the vertical linesegment SM, which is longer than the shortest distance between the twotrajectories (at the same time t). The trajectories are illustrated withcontrol nodes marked as points. Separation minimum SM (e.g. 5 miles) isdisplayed darker, with the extra margin EM displayed less dark. In thiscase, the two trajectories T1, T2 are too close in space-time, soseparation will be attempted by applying a repulsive force to bothtrajectories T1, T2.

In an attempt to resolve this conflict, a repulsive force will begenerated on both trajectories (or just one aircraft trajectory if theother is a weather cell, etc.). Since the point of closest approach (andgreatest conflict) is between Control Points, that point on eachtrajectory cannot be directly moved. Instead Target Points arecalculated for adjacent Controls Points on each side of the conflict.

The diagram in FIG. 10 shows the algorithm for calculating the TargetPoint B for current point b, and likewise, the Target Point C forcurrent point c. Target Points B and C are calculated by sampling thecubic spline a-P at time b, and cubic spline P-d at time c. Once TargetPoints B and C are calculated, the process of moving Control Points ishanded off to the higher-level deformation algorithms described above.

FIG. 11 provides another look at the process of at the generating TargetPoints from deconflicting two trajectories. FIG. 11 uses P and P′notation, but otherwise is similar. The trajectories are suggestive of awider range of shapes than FIG. 10. Otherwise, FIGS. 10 and 11 describesimilar dynamics.

Note that repulsion alone will tend to result in separated trajectories,yet with unseemly bumps. However, the elastic force will tend to smoothout any isolated bumps in trajectories, yielding smoother (and generallyshorter) overall paths. FIG. 12 shows the results of multiple repulsionand elastic iterations, and the resulting separated and smoothtrajectories. After a few repulsion and elastic iterations ofdeformation, the trajectories in FIG. 10 are separated, including extraadditional margins AM, and smoothed as well.

The examples of trajectory conflicts are visually compelling. However,since the time dimension of the trajectories is not obvious, the pointof closest approach at same time may not be where the trajectoriesappear to cross each other. FIG. 13 illustrates such situation. FIG. 13is similar to FIG. 10, except that the trajectories appear to intersect.In fact the closest approach at the same time is where the vertical lineis shown. Nevertheless, the process of determining the Target Points isthe same as before.

Pseudocode Sample 3 corresponds to the sub-task of applyingrepulsion/separation force to closest approach of conflictingtrajectories. Such pseudocode generates Target Points to implementrepulsion/separation operations, (expanding and filling in the detailsof line 2.1.iii.1 of Pseudocode Sample 2).

Pseudocode Sample 3 1. Begin with a pair of trajectories (or trajectoryand a storm cell) that violate separation minima. 2. For each of the twotrajectories (or one trajectory if the other element is a storm cell,etc.) 3. Find the point p of closest approach with the other trajectory(or storm cell) 4. Draw the line segment connecting the two points ofclosest approach of these two trajectories 5. Extend the line segmentsymmetrically to a distance of separation minimum plus margin 6. Point Pis as the far end of this line segment in the direction away from theother trajectory 7. Point b is the nearest Control Point to point p inthe downward time direction 8. Point a is the Control Point whichprecedes point b 9. Point c is the nearest Control Point to point p inthe upward time direction 10. Point d is the Control Point whichsucceeds point c 11. Calculate the cubic splines a-P and P-d 12.Calculate point B by sampling a-P at time b (i.e. at the timecorresponding to point b) 13. Calculate point C by sampling P-d at timec 14. Point B is a new Target Point for point b 15. Point C is a newTarget Point for point c 16. Hand these two points off to the pseudocodefor the high-level re- calculation algorithm above

FIG. 19 is a flowchart representing a process for determining repulsionforces. A routine 1900 begins at operation 1902, where trajectoryrecalculator 584 identifies the first and second trajectories thatviolate separation minima. From operation 1902, the routine 1900proceeds to operation 1904, where trajectory recalculator 584 invokesrepulsion module 586 which identifies the point of closest approach (p)of first trajectory with second trajectory. From operation 1904, theroutine 1900 proceeds to operation 1906, where the repulsion module 586computes and stores in memory coordinate data representing a linesegment connecting the two points of closest approach. From operation1906, the routine 1900 proceeds to operation 1908, where the repulsionmodule 586 computes and stores in memory data representing extensionsthe line segment symmetrically to a distance of the value for theseparation minimum plus margin. It should be appreciated that in variousembodiments, the trajectory management engine 524 or any of thecomponents thereof need not graphically render any of the trajectories,control points, target points, bisecting line segments, extensionsthereof or margins, but may be able to calculate and store datarepresentative of such data entities. From operation 1908, the routine1900 proceeds to operation 1910, where the repulsion module 586calculates the cubic splines of a-p and p-d. As described above in FIG.10, point P is a point at the far end of the vertical line segment inthe direction away from the other trajectory. Point b is the nearestcontrol point to point p in the downward time direction. Point a is thecontrol point which precedes point b. Point c is the near control pointto point p in the upward time direction and point d is the control pointwhich succeeds point c.

From operation 1912, the routine 1900 proceeds to operation 1914, wherethe repulsion module 586 calculates the point B by sampling a-P at timeb corresponding to point b. From operation 1914, the routine 1900proceeds to operation 1916, where repulsion module 586 calculates pointC by sampling P-d at time c corresponding to point c. From operation1916, the routine 1900 proceeds to operation 1918, where the repulsionmodule 586 stores point B as new target point for point b. Fromoperation 1918, the routine 1900 proceeds to operation 1920, where therepulsion module 586 stores point C as new target point for point c.

Elasticity/Smoothing Algorithm

Applying a repulsive force for maintaining separation is a powerfultechnique. However, this force alone is insufficient for generatingstable trajectories. Such paths are under specified causing instabilityof path locations, or “Brownian Motion” as paths remain restless. Inthese algorithms, an internal force of elasticity is applied to eachtrajectory causing the trajectories to follow ever more flyable,relatively shorter curved paths, conserving fuel, while stillmaintaining separation via the repulsive inter-trajectory force.Elasticity can be thought of the tendency for short sections of atrajectory to imitate the natural curve of longer sections of thetrajectory. With the removal of obstacles, elasticity will return thetrajectory to its initial cubic spline connecting the entry and exitpoints in the space. However, since obstacles are endemic to a crowdedairspace, the force of elasticity will do its best under whatevercircumstances and separation issues the trajectory finds itself within,in any particular moment. A beneficial emergent property associated withelasticity is that all of the applied forces tend to propagatethroughout the airspace. “Pressure” from highly conflicted regions ofthe airspace cause outward expansion, thus reducing local density.Without elasticity, this emergent property of “pressure” is negligible.Elasticity is applied by using the same cubic spline mathematicalalgorithm used to generate trajectory paths from Control Nodes. Theeffect of this algorithm is to reduce accelerations along thetrajectories. Reducing accelerations has the bonus of makingtrajectories more flyable.

Elasticity acts on trajectories internally. In addition, this force onlyacts on Control Points, and only uses neighboring Control Points for thecalculation. As with all forces in these algorithms, this force producesa Target Point. Elasticity is accomplished by reducing accelerations atControl Points. This has the effect of smoothing trajectories. Theprocess of reducing accelerations makes use of the theorem that maximumaccelerations on a cubic spline occur at their end points. Therefore,any point sampled on a cubic spline will have an acceleration less isthan or equal to the accelerations at the end points. For a ControlPoint b with an excessive accelerations, consider the Control Points aand c adjacent to b. Construct the cubic spline a-c. Then generate pointB by sampling a-c at time b. FIG. 14 illustrates the process of applyingthe “force” of elasticity to Control Point b on a trajectory. Constructthe cubic spline a-c. Then generate point B by sampling a-c at time b.In FIG. 14, Point B is a Target Point for Control Point b—which can beused to guide deformation of the trajectory towards point B, asdescribed above in the high-level re-calculation algorithms.

Pseudocode Sample 4 corresponds to the sub-task of applyingelasticity/smoothing force to all Control Points on all trajectories.Such pseudocode generates Target Points to implementelasticity/smoothing operations (expanding and filling in the details ofline 2.1.iii.2 and continuing from line 16 above).

Pseudocode Sample 4 17. Begin with a Control Point b on a trajectory 18.Control Point a immediately precedes point b 19. Control Point cimmediately succeeds point b 20. Construct cubic spline a-c 21.Calculate point B by sampling a-c at time b (i.e. at the timecorresponding to point b) 22. Point B is a new Target Point for ControlPoint b 23. Hand point B off to the pseudocode for the high-level re-calculation algorithm above

FIG. 20 is a flowchart representing a process for elasticity. A routine2000 begins at operation 2002, where the trajectory recalculator 584invokes elasticity module 588 which identifies control point b on atrajectory. From operation 2002, the routine 2000 proceeds to operation2004, where the elasticity module 588 constructs cubic spline a-c. Fromoperation 2004, the routine 2000 proceeds to operation 2006, where theelasticity module 588 calculates point B by sampling spline a-c at timeb corresponding to point b. From operation 2006, the routine 2000proceeds to operation 2008, where the elasticity module 588 stores pointB as new Target Point for control point b.

Bounding/Limits Algorithm

There are three “forces” which act on trajectories: repulsion,elasticity, and bounding. The first two, repulsion and elasticity,deform the trajectories away from obstacles while maintaining smoothpaths. However, without bounding aircraft speed within specified limits,the repulsion and elasticity algorithms might bring an aircraft to afull stop in the sky to wait out a conflict, or speed up excessively.Without limits on speed, solving a congested airspace will alwayssucceed simply by expanding the trajectory snarl like inflating aballoon. In this fashion, some trajectories would go far out of theirway to avoid conflicts, yet still arrive on time, but needing to flyexcessively fast to do so. The bounding “force” acts on all trajectoryControl Points to revise their trajectories towards a default cruisingspeed for the specific aircraft. Note that possible excessiveaccelerations of aircraft do not need to be handled by theBounding/Limits algorithm. Accelerations are addressed by theElasticity/Smoothing algorithm above. The Bounding/Limits algorithm isset forth below. For any Control Point, the default cruise speed for theaircraft (flying the trajectory) is the de facto Target Point.

Pseudocode Sample 5 corresponds to the sub-task of applyingbounding/limits force to all Control Points on all trajectories. Suchpseudocode generates Target Points to implement Bounding/Limitsoperations. (expanding and filling in the details of line 2.1.iii.3, andcontinuing from line 23 above.)

Pseudocode Sample 5 24. Begin with a Control Point p on a trajectory 25.Construct point P with same values as p 26. Change the velocity so itsnew magnitude is the default speed for the trajectory's aircraft 27.Point P is a new Target Point for Control Point p 28. Hand point B offto the pseudocode for the high-level re- calculation algorithm above

This pseudocode continues as line 2.a.iv of Pseudocode Sample 2. Notethat point p and point P have identical position—only the velocity maybe different. The positions of the Control Point and the Target Pointare same. Hence, the Bounding/Limits operation is harder to visualize.

FIG. 21 is a flowchart representing a process for bounding in accordancewith the disclosure. A routine 2100 begins at operation 2102, where thetrajectory recalculator 584 invokes bounding module 590 which identifiescontrol point p on a trajectory n. From operation 2102, the routine 2100proceeds to operation 2104, where the bounding module 590 constructspoint P with the same values at p. From operation 2104, the routine 2100proceeds to operation 2106, where the bounding module 590 modifies thevelocity value so the new magnitude of the velocity is the default speedfor the aircraft trajectory n. From operation 2106, the routine 2100proceeds to operation 2108, where the bounding module 590 stores point Pas new target point for control point p.

In light of the foregoing, the reader may appreciate that the disclosedsystem and technique utilizes algorithms, agent-based structures tocontact the existence of phase transition structure in an airspace as an“early warning” prior to “full” airspace, allowing the airspace“fullness” to be anticipated and remedied before the airspace becomesunsafe.

Below the disclosed system and techniques have been described withreference to trajectories for aircraft, including use of amultidimensional trajectory, it will be obvious to those recentlyskilled in the arts how these concepts may apply to other land, sea orother aircraft vehicles and how the projection of trajectoriesassociated with such vehicles can be similarly used to safelyde-conflict two trajectories from each other or from various obstaclesas well as identify when a particular travel space or area isapproaching a phase transition.

As described herein, the disclosed system and techniques also providespilots with advisory suggestions for making changes in an aircraft'strajectory that will reduce fuel consumption. Such tool, in the form ofa software application, utilizes the algorithms described herein toposition the aircraft in an optimal glide path, initially.

Fleet Trajectory Operations

According to another aspect of the disclosure, disclosed is a system andmethod for planning, disruption management, and optimization ofnetworked, scheduled or on-demand air transport fleet trajectoryoperations from gate-to-gate (departure to arrival airport).

Existing flight planning, flight plan management, and air trafficservices for aircraft fleet operations results in two shortcomings.These two shortcomings impose penalties in cost, fuel burn, carbonemissions, time, noise, and fleet capacity (seats available per day)compared to what is possible through trajectory-based optimization andairspace operations. First, the labor pool utilized by today's operatorsof on-demand fleets is excessive, when compared to the workforcerequired using the disclosed system for fleet management. Second,conventional flight planning and management creates a solution for timeand fuel burn for an individual flight segment that is best suited forscheduled fleet operations (as contrasted with on-demand fleetoperations). Second, existing air traffic services frequently result ina route of flight, altitude, and speed that varies significantly fromthe optimum solution for an individual flight segment (as contrastedwith optimized and de-conflicted trajectories). Through the applicationof a fleet trajectory optimization and management system andtrajectory-based air traffic management services, these penalties can bemitigated.

In prior art, systems and methods for managing air traffic flow havebeen limited to the optimization of individual aircraft flight segments,by individual flight plan. These methods provide for benefits to eachindividual aircraft cost and performance for a flight segment (takeoffto touchdown). The limitation of such past methods is that they do notaccount for the benefits possible by optimizing an entire fleetoperation and allocating the resulting cost and performance assignmentsto each aircraft. According to one aspect of the disclosed system andtechniques, the individual aircraft flight path trajectory informationis optimized in the context of a large number of aircraft operating as afleet, on interdependent flight segments, solving the limitation ofprior art methods and producing benefits that go beyond the summation ofindividual aircraft flight path optimization benefits to include thenetwork-induced benefits. The disclosed implementation results insavings in energy, emissions, and noise, and increases the number offleet seats- or flights-per-day, and reduces empty seats- or emptyflights-per-day.

In the existing National Airspace System, systems and methods formanaging air traffic flow have been limited the optimization ofindividual aircraft flight segments, by individual flight plan. Thesemethods provide for benefits to each individual aircraft cost andperformance for a flight segment (takeoff to touchdown). The limitationof these past methods is that they do not account for the benefitspossible by optimizing an entire fleet operation and allocating theresulting cost and performance assignments to each aircraft.

According to one aspect of the disclosure, system 640 of FIG. 15Acombines the functions of generating, assigning, and communicatingflight path trajectory information to aircraft in a networked, on-demandfleet operation for the benefit of optimizing the performance of theentire fleet in near real time. The information assigned andcommunicated to the aircraft includes, but is not limited to, altitude,speed, power settings, heading, required time of arrival (at pointsalong the trajectory), and aircraft configuration. In one embodiment,the optimized parameters of fleet performance may include time, cost,energy, and environmental factors such as carbon and other emissions,and noise. The optimization period over which the generation of theflight path information is computed may include any of minute-by-minute,hour-by-hour, day-by-day, and annualized. In another embodiment, theflight path information communicated to the aircraft may be in the formof a secure, assured delivery protocol, machine language or otherappropriate instruction format suitable for Implementation directly intothe flight or trajectory management computer system (a Flight ManagementSystem for example).

In the disclosed system and method, the Individual aircraft flight pathtrajectory information is optimized in the context of a large number ofaircraft operating as a fleet, on interdependent, de-conflicted flightsegments. The disclosed system solves the limitation of past methods andproduces benefits that go beyond the summation of individual aircraftflight path optimization benefits to include the network-inducedbenefits. This implementation results in savings in energy, emissions,and noise, increases the number of fleet seats- or flights-per-day, andreduces empty seats- or flights-per-day.

More specifically, a system and method is disclosed herein foroptimizing the performance of a networked, scheduled or on-demand airtransport fleet operations in near real time. The invention implementsdigital communication systems, high fidelity fleet tracking systems,fleet-wide trajectory optimization software, digital customer interfacesystems, weather information, National Airspace System infrastructurestatus information, and air traffic flow negotiation processes. Theimplementation includes near real-time information exchange, from afleet command center (or Airline Operations Center—AOC) for flighttrajectory management, to aircraft trajectory or flight managementsystems (a Flight Management System (FMS) for example), electronicflight bags (EFBs), pilots, or piloting systems. The input to theaircraft is made throughout the fleet that is operating in aninterdependent, regionally distributed set of interdependent flightsegments. The trajectory optimization calculations allow for frequent,near-real-time updating of trajectories (e.g., in seconds or minutes asappropriate to the need), to account for the impact of disruptions oneach flight, based on the principle cost function being optimized (e.g.,corporate return on investment for example). The disruptions accountedfor include, but are not limited to, weather, traffic, passengers,pilots, maintenance, airspace procedures, airports and air trafficmanagement infrastructure and services. The system operates byintegrating aircraft flight plan optimization capabilities, real-timeaircraft tracking capabilities, airborne networking data communicationcapabilities, customer interface, and a fleet optimization system. Thebenefits in fleet performance exceed the benefits possible only usingindividual aircraft flight plan optimization systems and methods.

The disclosed on-demand fleet operations employ aircraft and a commandinformation center furnished with performance-based navigation,surveillance and communications capabilities, including a trajectory orflight management system (an FMS, for example) capable of requirednavigation performance, a transponder (or other position-reportingsystem) capable of providing near real time aircraft position fromwheels rolling to wheels stopped along a trajectory, a command centerequipped with fleet optimization software, an airborne networking datacommunication function, a digital customer interface, weatherinformation, National Airspace System infrastructure status, and adigital interface with the air navigation services provider (FAA AirTraffic Control for example). These capabilities combine to provide themeans for generating, optimizing, and distributing flight pathtrajectory management information for large fleets of interdependentaircraft flight segments in near real time.

At each point of a flight path trajectory, from wheels rolling at thestart of the flight to wheels stopped at the end of the flight, system640 of FIG. 15A, which includes the trajectory management engine 524 ofsystem 500 provides current status and prognostic information to thecommand information center 650 and to the pilots of aircraft 576A-B,including, but not limited to speed, altitude, fuel consumed, fuelremaining on board, wind and other weather information, time remainingto destination, four-dimensional flight trajectory points flown and tobe flown, and required times of arrival at points along the trajectory.The flight trajectory management engine 524 proposes an optimization ofthe flight trajectories for each flight in the fleet, based on optimumfleet performance.

System 640 can be implemented using existing technologies in theimmediate future, with continuing improvements over the few years. Part135 companies could be the immediate customers of this system. In themid term, the innovation would be appropriate for marketing in theaviation sector to Part 121 (scheduled) operators, and perhaps to FAAAir Traffic Management as automation operations tools.

The system and technique disclosed herein can provide a trajectoryoptimization and real-time management system for operation of on-demandaircraft fleets. The system and method can be further refined foroptimizing the performance of a networked, on-demand air transport fleetoperation in near real time. The fleet optimization may be implementedthrough assignment and management of trajectories (flight plans) foreach aircraft. These trajectories may be produced to satisfy multipleconstraints, including customer-required destination time-of-arrival,minimized time-of-flight, optimized fuel burn (and carbon), and optimumDirect Operating Cost (DOC). These trajectories may be de-conflictedwithin an operator's fleet and the available regional air traffic flowdata. The trajectories thus optimized may be referred to as “ReferenceBusiness Trajectories (RBTs),” and may include optimum as well asoptional (sub-optimum) choices of routing, altitude, and speed. Thedisclosed system may submit and negotiate the RBTs with the FAA AirTraffic Operations and the aircraft fleet (through Electronic FlightBags), in digital form. The system may supports Air Traffic approval ofpreferred routes for reduced fuel burn, reduced flight times, andreduced emissions through shorter segments flown at optimum altitudes,including seamless climb to cruise and optimal profile descents. Thesepreferred routes would include Terminal En Route trajectories in thenear term and RNAV/RNP trajectories in the mid-term.

The disclosed fleet trajectory optimization and management system 640may be implemented as conceptually illustrated in FIG. 15A. System 640comprises system 500 and specifically trajectory management engine 524,as disclosed herein to ensure management of trajectories for each craftin the fleet, including too jet trajectory separation and recalculation.System 640 further comprises a high fidelity fleet tracking system 645which enables tracking of data from aircraft. System 645 may support theITT ADS-B infrastructure, for example. In the farther term, additionalmulti-mode communication infrastructure options may offer the potentialfor robust and ubiquitous aircraft position information. Theimplementation of fleet tracking will have a stabilizing effect on fleetoperations, reducing inefficiencies induced by lack of detailed aircraftposition information. The fleet tracking system will producetrajectory-as-flown data that allows for more frequent and more accuratere-optimization runs by the system.

System 640 further comprises a digital communication system forcommunication between fleet aircraft 576A-B and system 640. In the nearterm, this function can be provided using Iridium devices on boardaircraft with data compression through an existing STC-ed FDU thatincludes bi-directional digital communications and GPS interface forposition reporting which augments tracking in airspace volumes notsurveilled by ADS-B). Multi-mode (Internet Protocols over VHF, Wi-Fi,broadband, Satcomm) communication infrastructure may also be utilizedsystem 642 provide robustness and ubiquity demanded in larger fleetoperations.

Weather information, indicated in FIG. 15A as database 572A may beimplemented, especially for winds aloft information, with DUATS to beused for the trajectory planning and real-time management function. Forconvective weather information, NOAA's Storm Prediction Center (SPC) mayprovide automated probabilistic thunderstorm height product that can beused initially for trajectory planning. For the longer term, System WideInformation Management (SWIM) offers the potential to significantlyreduce the cost and time required to rapidly create accurate flighttrajectory plans. The goal will be to produce accurate trajectory plansin seconds as contrasted with the length of time (and higher cost) ofthe existing flight planning process. An additional source ofhigh-fidelity weather data is Airdat, Inc. which provides commercialweather forecasting services based on airborne-derived meteorologicaldata feeds from sensors on aircraft.

National Airspace System infrastructure status information indicated inFIG. 15A as database 572B may be implemented, with the existing NOTAMSsystem. This FAA system is being modernized and streamlined over thecoming few years. The new SWIM system is planned to support very rapidincorporation of infrastructure and system information for trajectory(flight plan) development and negotiation with Air Traffic operations.

Air traffic flow negotiation processes may be performed utilizing theprocess illustrated with reference to FIG. 17A-B. The FAA is workingtoward automation of flight planning and trajectory-based systems astools for air traffic managers. The existing tools include ERAM (enroute automation management), URET (user request evaluation tool), TMA(traffic management automation), and others. The planned integration andautomation of these tools leads to the ability of the future FAA AirNavigation Services Provider (ANSP) to accept, optimize, andre-negotiate trajectory plans with aircraft operators. The applicationof and expanded NextAero dynamic trajectory management capability wouldbe applicable to the national airspace management functions.

System 640 disclosed herein provides near real-time information exchangebetween a fleet command center 650 and the aircrafts 576A-B. In thisillustration, the aircraft are equipped with a flight management system(a Flight Management System (FMS) for example), electronic flight bags(EFBs), ADS-B IN and OUT, and digital communication capabilities. Thetrajectory information input to the aircraft is made throughout thefleet in near real time. The aircraft operate in an interdependent,regionally distributed set of flight segments. The trajectoryoptimization calculations allow for frequent updating of trajectories(e.g., approximately every 10-15 minutes) to account for the impact ofdisruptions on each flight. Trajectories are planned to satisfy theprinciple cost function being optimized (corporate return on investmentfor example). The disruptions accounted for include, but are not limitedto, weather, traffic, passengers, pilots, maintenance, airspaceprocedures, airports and air traffic management infrastructure andservices. The system operates by integrating aircraft flight planoptimization capabilities, real-time aircraft tracking capabilities,airborne networking data communication capabilities, customer interface,and a fleet optimization system. The benefits in fleet performanceexceed the benefits possible only using individual aircraft flight planoptimization systems and methods.

The disclosed fleet trajectory management system serves as a foundationfor a significant advancement in fleet network performance. Threeperformance benefits are possible: (1) reduced operating expenses forflight planning and flight trajectories management (fuel, time, andmaintenance), (2) increased revenue through aggregation of passengers,and (3) increased daily “lift” (segments/seats per aircraft per day).The first two benefits accrue for both on-demand and scheduledoperators; the third benefit accrues to on-demand operators.

The disclosed fleet trajectory management system serves as a foundationfor a significant advancement in fleet network performance. Severalperformance benefits are possible: (1) reduced operating expenses forflight planning and flight trajectories management (fuel, time, andmaintenance), (2) increased revenue through aggregation of passengers,(3) increased daily “lift” (segments/seats per aircraft per day), and/orreduced capital expenses (cost of equipment).

It will be obvious to those reasonably skilled in the art thatmodifications to the systems and processes disclosed herein may occur,without departing from the true spirit and scope of the disclosure. Forexample, any two elements which communicate over a network or directly,may utilize either a push or a pull technique in addition to anyspecific communication protocol or technique described herein. Further,notwithstanding the network implementation described, any existing orfuture network or communications infrastructure technologies may beutilized, including any combination of public and private networks. Inaddition, although specific algorithmic flow diagrams or data structuresmay have been illustrated, these are for exemplary purposes only, otherprocesses which achieve the same functions or utilized different datastructures or formats are contemplated to be within the scope of theconcepts described herein. As such, the exemplary embodiments describedherein are for illustrative purposes and are not meant to be limiting.

What is claimed is:
 1. A computer program product for use with acomputer system, the computer program product comprising anon-transitory computer readable medium having embodied therein programcode for determining the capacity of an airspace to safely handlemultiple aircrafts, the computer program product comprising: A) programcode for acquiring data describing a plurality of trajectories eachrepresenting an aircraft or an obstacle within an airspace, B) programcode for recalculating selected of the plurality of trajectories at timeintervals; C) program code for identifying conflicts between pairs ofaircraft rajectories or between an aircraft trajectory and an obstacletrajectory; D) program code for modifying a trajectory of one of thepair of aircraft trajectories or the aircraft trajectory in conflictwith the obstacle trajectory; and E) program code for repeating B)through D) a predetermined number of cycles until no conflicts areidentified in C), else provide an indication that the airspace isapproaching unsafe capacity to handle additional trajectories; whereinthe data describing the trajectory for each aircraft comprises amulti-dimensional data structure stored in computer memory andcomprising data representing a first time value and a second time value.2. The computer program product of claim 1 wherein D) comprises: D1)program code for applying a repulsion/separation process to a closestapproach of first and second trajectories or a first trajectory and anobstacle.
 3. The computer program product of claim 1 wherein in (D)comprising: D1) program code for applying an elasticity/smoothingprocess to control points of the plurality of trajectories.
 4. Thecomputer program product of claim 1 wherein in (D) comprising: D1)program code for applying a bounding/limits process to control points ofthe plurality of trajectories.
 5. The computer program product of claim1 further comprising: F) program code for initializing in memory aplurality of parameters defining a model of the airspace.
 6. Thecomputer program product of claim 1 further comprising: F) program codefor displaying data defining at least one of the plurality oftrajectories.
 7. A computer program product for use with a computersystem, the computer program product comprising a non-transitorycomputer readable medium having embodied therein program code formanaging aircraft within an airspace, the computer program productcomprising: A) program code for, upon entry of an aircraft into anairspace, receiving from the aircraft and storing in a computer memory,data describing a trajectory representing the aircraft; B) program codefor periodically re-calculating the trajectory representing theaircraft; C) program code for identifying conflicts between thetrajectory representing the aircraft and another trajectory representingone of another aircraft and an obstacle within the airspace; D) programcode for modifying the trajectory representing the aircraft; and E)program code for communicating data representing a modified trajectoryto the aircraft; wherein the data describing the trajectory representingthe aircraft comprises multi-dimensional data comprising a first timevalue and a second time value.
 8. The computer program product of claim7 wherein the data representing a modified trajectory comprises any ofaircraft altitude, speed, power settings, heading, required time ofarrival, and aircraft configuration.